We're in the process of overhauling the Brainfood.com site and I'm trying to leverage the SFA system. I see some simple things that don't work, like it not storing address and telephone information, but those are easy fixes. I'm more interested in what the workflow is for dealing with leads on an ongoing basis.
To me it would be logical if a Lead could be graduated to an Opportunity and an Opportunity could, in turn, be graduated to a Project. Leads seem mostly to be a special case of a party and the use of the partyStatusId as a lead state tracking mechanism seems like an abuse to me. It seems to me that the process of qualifying a lead should probably have its own distinct data element. Depending on your point of view, it could be a WorkEffort or at least a CommunicationEvent that has child CommunicationEvents associated with it. Thoughts? -- Ean Schuessler, CTO Brainfood.com [hidden email] - http://www.brainfood.com - 214-720-0700 x 315 |
On Apr 16, 2009, at 11:14 AM, Ean Schuessler wrote: > We're in the process of overhauling the Brainfood.com site and I'm > trying to leverage the SFA system. I see some simple things that > don't work, like it not storing address and telephone information, > but those are easy fixes. I'm more interested in what the workflow > is for dealing with leads on an ongoing basis. > > To me it would be logical if a Lead could be graduated to an > Opportunity and an Opportunity could, in turn, be graduated to a > Project. Leads seem mostly to be a special case of a party and the > use of the partyStatusId as a lead state tracking mechanism seems > like an abuse to me. It seems to me that the process of qualifying a > lead should probably have its own distinct data element. Depending > on your point of view, it could be a WorkEffort or at least a > CommunicationEvent that has child CommunicationEvents associated > with it. > > Thoughts? A couple of, perhaps wild and crazy, thoughts: 1. to get the process down and work together to refine it and make the implementation match it would be _great_; this is the sort of effort that I think will be the next great phase of existence for OFBiz (and what I plan to push in coming months and talk about at ApacheCon in Nov and to some extent at OSCON in July); the documents for this are in a new space on the docs.ofbiz.org confluence site here: http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index (in the OFBREQDES space) the page for the early part of the sales process is here: http://docs.ofbiz.org/display/OFBREQDES/Sales+Representative+Seeks+Prospects+and+Opportunities As you can see there isn't much in that story (I haven't gotten to it yet... :) ), just some ideas about things that should go into the story. 2. I think the most literal modeling of this would involve extending the PartyRole entity to add a statusId (and perhaps add a PartyRoleStatus entity to keep the status history); I got to that though by starting with: what is a lead? It is basically a role that a party can be in, and for that specific role we want to track the party's status; this concept could be used for other roles as well, but seems to make good sense for a lead, account, etc in the sales world -David |
Great stuff gents. Ean, if you want to write down some of your thoughts on where we should go next, I'll be happy to dive in there and offer some feedback as well as getting people rolling on making this type of thing happen for us all.
Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 ----- "David E Jones" <[hidden email]> wrote: > On Apr 16, 2009, at 11:14 AM, Ean Schuessler wrote: > > > We're in the process of overhauling the Brainfood.com site and I'm > > > trying to leverage the SFA system. I see some simple things that > > don't work, like it not storing address and telephone information, > > > but those are easy fixes. I'm more interested in what the workflow > > > is for dealing with leads on an ongoing basis. > > > > To me it would be logical if a Lead could be graduated to an > > Opportunity and an Opportunity could, in turn, be graduated to a > > Project. Leads seem mostly to be a special case of a party and the > > > use of the partyStatusId as a lead state tracking mechanism seems > > like an abuse to me. It seems to me that the process of qualifying a > > > lead should probably have its own distinct data element. Depending > > > on your point of view, it could be a WorkEffort or at least a > > CommunicationEvent that has child CommunicationEvents associated > > with it. > > > > Thoughts? > > A couple of, perhaps wild and crazy, thoughts: > > 1. to get the process down and work together to refine it and make the > > implementation match it would be _great_; this is the sort of effort > > that I think will be the next great phase of existence for OFBiz (and > > what I plan to push in coming months and talk about at ApacheCon in > Nov and to some extent at OSCON in July); the documents for this are > > in a new space on the docs.ofbiz.org confluence site here: > > http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index > > (in the OFBREQDES space) > > the page for the early part of the sales process is here: > > http://docs.ofbiz.org/display/OFBREQDES/Sales+Representative+Seeks+Prospects+and+Opportunities > > As you can see there isn't much in that story (I haven't gotten to it > > yet... :) ), just some ideas about things that should go into the > story. > > 2. I think the most literal modeling of this would involve extending > > the PartyRole entity to add a statusId (and perhaps add a > PartyRoleStatus entity to keep the status history); I got to that > though by starting with: what is a lead? It is basically a role that a > > party can be in, and for that specific role we want to track the > party's status; this concept could be used for other roles as well, > but seems to make good sense for a lead, account, etc in the sales > world > > -David |
Free forum by Nabble | Edit this page |