[Vtigercrm-developers] email tracking and list enforcement
Matthew Brichacek
mmbrich at fosslabs.com
Wed May 24 12:12:56 PDT 2006
I like the idea of a 5.1 branch to start this work on. Since this
really is going to set the stage for the list management system in
vtiger and just isn't a good candidate to throw in a week before your
beta release :).
I would put the time for list management, bulk emailing and email
tracking at somewhere near 2-3 weeks given how much time I have lately.
I think all together it took me 3-4 days of near non-stop work to get
these features into 4.x.
Anyways, after talking with some other vtiger users I have a list of
additions I would like to get moved into 5.1+. Some of this work is
going to be done because it's sponsored, I'll put a star next to those
so you'll know which ones are at risk of being dropped if the client
happens to decide against the feature.. Also speak up if you object to
any of these feature going into 5.1+ releases.
These are mostly in-order as I plan to enable them:
1) List Management
2) Bulk email and tracking capabilities
3) De-Duplication system
4) Expand on 4.x Click-to-Dial support by enabling skype, etc and make
it a user configurable option
5) Per-campaign custom fields
6) Avery label maker -- JLee donated what will probably become the
framework for this. I plan to add a template engine and maybe even
envelope, postcard, etc makers :). <-"printing press" module? :)
7) Per-User email templates (JLee handed over some example code for this
too)
8) Tab/Module Builder
9) OOo Mail merge plugin (*)
10) OOo document parser (*)
11) if 9 & 10 are completed I may build a document management system of
some kind eventually. (something like knomos.org has)
12) Expand (and finish) much of the joomla<->vtiger work started in 4.x
If you think any of these will scratch an itch for you then speak up and
I'll be glad to help you with any questions you have.
Matt
On Wed, 2006-05-24 at 05:31 -0700, Richie wrote:
> Team, I am not sure if we do have a plan in place to have the list
> management part in. No doubt it can be done but the overall goal will
> be to have a logical flow in the system to use the feature which I
> suspect can be achieved at such short notice. Saint too has to be
> brought into the picture and he needs time to evaluate and suggest a
> flow. Then, comes the UI deliverables and the testing,
> bug-fixing,etc.
>
> I personally like the feature, in fact, what Matt has said is the
> proper way in which the feature should be provided. I do concede that
> the campaign management feature is as of now, more a place holder than
> anything.
>
>
> But, I am not sure if this is the right time to get this in. The Beta
> is just round the corner and we are better off testing whatever we
> have.
>
> Just for the info, I have asked Matt for the estimate for getting this
> feature in though but I am not in favour of adding any new features at
> this juncture.
>
>
> Your views are welcome.
>
> Richie
>
>
>
>
> ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ----
>
> This is true, I've been known to change my mind before :) ..
> but this is
> something I really want to get moved into 5.x for my own
> benefit as well
> (because all you hackers are going to make it better than I
> ever
> imagined right?), on the other hand though I will surely
> introduce some
> bugs with this feature and that's not what feature freezes are
> for ;).
>
> Anyways, if there is enough agreement in how list management
> should be
> done I'm willing to merge it in now if Richie still allows. I
> am still
> not sure how to tackle the list management though, I want to
> improve on
> how I did it for 4.x but haven't come up with any ideas on
> just how to
> do that yet.
>
> Matt
>
> On Tue, 2006-05-23 at 18:02 -0300, Sergio A. Kessler wrote:
> > I'm afraid that if you let pass this windows (as you say,
> richie
> > opened you a windows) while you are with this thing with the
> hot
> > hands, in the future things could cold and maybe you decide
> that's not
> > worth the effort...
> >
> > +1
> >
> > /sak
> >
> > On 5/23/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote:
> > > I'm not real sure what Richies plan is moving forward, he
> wrote me this
> > > AM and asked me to put the email tracking stuff in but I
> declined
> > > because we are still in feature freeze and because I
> wanted opinions on
> > > list management (not to mention I am still busy with
> webmails stuff).
> > >
> > > So IOW, I dunno, if I get the thumbs up to add it to v5
> then I will,
> > > otherwise I will wait until the next window opens up and
> do what I can
> > > to merge it in then.
> > >
> > > As far as list management, we're on the same page,
> currently if the user
> > > clicks on the "Unsubscribe from all campaigns" link in the
> unsub page
> > > they will have the contactdetails.emailoptout flag set and
> never be
> > > emailed again from vtiger.
> > >
> > >
> > > Matt
> > >
> > > On Tue, 2006-05-23 at 16:23 -0300, Sergio A. Kessler
> wrote:
> > > > Matthew, I think the email flag by campaign is rigth,
> > > > maybe the contactdetails.emailoptout could be used for
> 'never ever
> > > > email this guy'
> > > >
> > > > btw, this is going in v5 ? or is is too late ?
> > > >
> > > >
> > > > /sak
> > > >
> > > > On 5/23/06, Matthew Brichacek <mmbrich at fosslabs.com>
> wrote:
> > > > > Hello All,
> > > > >
> > > > > I'll be getting ready to drop the email tracking
> capabilities into 5.x
> > > > > soon and I would like peoples opinions on list
> management...
> > > > >
> > > > > In our current deployment we've created an abstracted
> list management
> > > > > system called the "Campaigns" module.. Imagine
> that :). Within this
> > > > > module I track all lists by the parent_id and not by
> entity. This is
> > > > > because some of our customers are large telemarketing
> organizations and
> > > > > wanted to be able to harvest lists from their leads DB
> and re-call them
> > > > > even if they had a previous do-not-call flag set from
> another campaign.
> > > > > There are other good reasons for list management too,
> I'll explain more
> > > > > bellow.
> > > > >
> > > > > I tied the list management into the custom views
> module, IE: if you
> > > > > create a custom view called "List 1" you will have a
> campaign created
> > > > > with a parent id == customviewid of List 1. The parent
> is where the
> > > > > tracking begins at so that if the list is simply
> duplicated (say for
> > > > > another newsletter) then the unsub list is maintained.
> If a new custom
> > > > > view is created, the parent_id is set to the new
> customviewid for the
> > > > > new campaign and the list unsubs are reset.
> > > > >
> > > > > I know that is confusing but it enforces list
> management and not at the
> > > > > entity level so it still allows for harvesting new
> lists from the db.
> > > > > Here is a simple scenario of how it works:
> > > > > 1) I create a custom view called "sales list" and
> click the "Add to
> > > > > Campaigns" checkbox and save it.
> > > > > 2) A new campaign with a subject of "Initial list
> creation" is created
> > > > > with a parent_id == cvid of "Sales List"
> > > > > 3) Set the campaign type == "Email" and the rest of
> the fields to
> > > > > whatever I want and save
> > > > > 4) New button appears in Campaign DetaiView for
> "Create/Edit Email" and
> > > > > "Bulk Mail". I create an email and mail it.
> > > > >
> > > > > Now, suppose one of my customers unsubs from this
> list. He won't ever
> > > > > be emailed from the "Sales List" or any of the
> children campaigns that
> > > > > are created from it. However, if I go create a
> "Newsletter List" custom
> > > > > view and add it to the campaigns that customer _will_
> be mailed again.
> > > > > Using the regular contactdetails.emailoptout would
> have stopped that
> > > > > customer from getting the newsletter list and is
> another good reason for
> > > > > list management instead of entity management for
> campaigns.
> > > > >
> > > > > So, what do you think? Far too complicated? Would you
> like to see a
> > > > > stricter set of unsub management rules? Or do you
> think this mix is
> > > > > just right?
> > > > >
> > > > > If you need further explanation just say so.
> > > > >
> > > > > Matt
> > > > >
> > > > > _______________________________________________
> > > > > This vtiger.com email is sponsored by Zoho Planner.
> Still scribbling down your To-Do's on bits of paper & palms of
> your hands? Try the AJAX enabled, personal organizer online,
> Zoho Planner for FREE instead! http://zohoplanner.com/?vt
> > > > >
> > > >
> > > > _______________________________________________
> > > > This vtiger.com email is sponsored by Zoho Planner.
> Still scribbling down your To-Do's on bits of paper & palms of
> your hands? Try the AJAX enabled, personal organizer online,
> Zoho Planner for FREE instead! http://zohoplanner.com/?vt
> > >
> > > _______________________________________________
> > > This vtiger.com email is sponsored by Zoho Planner. Still
> scribbling down your To-Do's on bits of paper & palms of your
> hands? Try the AJAX enabled, personal organizer online, Zoho
> Planner for FREE instead! http://zohoplanner.com/?vt
> > >
> >
> > _______________________________________________
> > This vtiger.com email is sponsored by Zoho Planner. Still
> scribbling down your To-Do's on bits of paper & palms of your
> hands? Try the AJAX enabled, personal organizer online, Zoho
> Planner for FREE instead! http://zohoplanner.com/?vt
>
> _______________________________________________
> This vtiger.com email is sponsored by Zoho Planner. Still
> scribbling down your To-Do's on bits of paper & palms of your
> hands? Try the AJAX enabled, personal organizer online, Zoho
> Planner for FREE instead! http://zohoplanner.com/?vt
> _______________________________________________
> This vtiger.com email is sponsored by Zoho Planner. Still scribbling down your To-Do's on bits of paper & palms of your hands? Try the AJAX enabled, personal organizer online, Zoho Planner for FREE instead! http://zohoplanner.com/?vt
More information about the vtigercrm-developers
mailing list