SFA lead handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SFA lead handling

Ean Schuessler
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
Reply | Threaded
Open this post in threaded view
|

Re: SFA lead handling

David E Jones-3

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

Reply | Threaded
Open this post in threaded view
|

Re: SFA lead handling

Tim Ruppert
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