I just finished up a neat little project where I got to help a client streamline how they were managing the monitoring of lead consumption among their sales members and making sure that they were not overspending in a particular region at another's detriment.
The Problem: The client is using Adwords to garner leads in various states. Their sales team members are selling in multiple states. They have a third party system for distribution of leads to the team members. This system has a toggle the team members are to use to indicate whether they are actively taking leads at a given time. When this flag is on for a team member, leads are sent to them. However, many team members were failing to turn their flag off. These members where then getting leads assigned to them when they might not even be in the office. This was to the detriment of other members who then would get none. Due to the agreement to provide members leads, this meant a lot of work tracking consumption, establishing quotas and trying to modify behavior. It also meant that sometimes the Adwords budget for particular campaigns would have to be increased in order to meet the internal agreements with the sales team. The cross region nature of sales member activity also meant that it could effect campaigns in multiple regions. They were tracking all this using a spreadsheet and a lot of leg work.
The Solution: Redpoint was asked to build a small tool to automate what the lead manager was having to spend too much of his time fretting about with the spreadsheet. In a short 6 weeks from Inception to Production Deploy we came up with a system to do this. The tool ultimately consisted of a web app and a poller service. The components pulled data from various web services including the distribution tool, internal employee data services, and Adwords. Most were RESTful - hence the title of this blog. The web app gave the lead manager a dashboard to monitor individual sales member consumption of leads against an assigned limit. This contributed to the calculation of potentially available leads for a given state. Once all members selling in a state had gotten all the leads they were supposed to, all campaigns in that state would be paused for the day. If the lead manager wanted to they could then increase a particularly good sales persons limit and allow them to sell more, or refocus a sales persons lead consumption to a particular state or states. The poller service was automated by a Windows Service using Quartz.net CronTriggers to assign various pollers to maintain the list of sales team members, the states they sold in, their lead consumption, the availability pool, and ultimately to pause or restart the Adwords campaigns appropriately.
The Result: The final tool, as it had evolved, quickly gained admiration from the executive team and the project sponsors. Even in its testing state, it had shown that it was more than just an automated valve for Adwords. The dashboards and multiple levels of control built into the solution allowed them to quickly see patterns in sales member activity and behavior. The flexibility of the Cron Triggers allowed them to schedule polls and resets as well as to automatically turn off all campaigns during down times and prevent 'greedy' team members from stock pilling all the leads while others were out of the office. This also assuaged executive fears of blowing the Adwords budget as they soon saw how this was an excellent emergency shutoff valve to control their spending.
For phase two they are already talking about the ease of creating trending and tracking data from what is being pulled as well as adding in different lead types and groupings.
As an Agilist, I appreciated this project as it had become an interesting, dynamic and interactive information radiator that would allow them to manage and change how they do business to meet the changing needs of their market and their staff.
Other Applications: Of course this sort of tool could be very useful to any growing company who is struggling to wrangle their Adwords budgets and their sales team's quotas. A similar tool could be useful to Scrum Masters, PMs or Team Leads to monitor and control story assignment within a team, by using the information from their story management system and assigning categories or even complexity sections to various members ("you did three '1 point' stories this iteration so far, you have to take a '2' or a '3' next" OR "You have been only taking stories involving that piece you created, for the rest of this iteration you need to take stories from other areas of the application"). While not so helpful with a small team, it could be very handy with a large distributed team - like the sale team in this case.
No comments:
Post a Comment