WebSeitz/wikilog
Sfa Via Issue Tracker Wiki
Whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness.

(backlinks off) (map off)
(search off)
last edited by BillSeitz on Jul 3, 2008 1:36 am

I love having an .

But what if you need an system? Should we build that into a separate ?

Or, can we use the features for ?

You have a page for the prospect (1 for company and 1 for each individual).

Then each "issue" is an interaction/event between a salesperson and a prospect. The "Owner" is the salesperson.

The issue criticality reflects the "hotness" of the prospect, maybe.

If it's scheduled, then the dueDate is the planned date/time.

If an item gets rescheduled, you change its dueDate.

When it happens, you keep that dueDate and set status=Closed.

Then your historical report by prospect is just a view.

Your calendar for a salesperson, past or future, is a filter of Issues.

The activity report for the team or a subteam is just a filter combining multiple Owners.

In the -s I've been in, that would pretty much be sufficient.

What am I forgetting?

Or an even simpler approach (say, where the sales cycle is shorter)

Every lead is an issue/ticket.

You lose the ability to have reports structured by specific interactions (during some time period) rather than by lead (all leads changed during the period). But if your sales cycle is relatively short-simple, then it's the close volume that counts, not the mid-cycle status updates.

See : | | | | |


 



Bill Seitz, fluxent at gmail dot com, Weblog