You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ean Schuessler <ea...@brainfood.com> on 2009/04/16 19:14:37 UTC
SFA lead handling
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
ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: SFA lead handling
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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" <da...@hotwaxmedia.com> 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
Re: SFA lead handling
Posted by David E Jones <da...@hotwaxmedia.com>.
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