SOP Friday: Sales Tickets and Sales Queues
karlp / Karl Palachuk
Many people use QuoteWerks or Quosal or some other tool for getting out quotes. Some people use the CRM module of their PSA. Some use Salesforce.com or another stand-alone CRM system. But many small shops don’t do enough quotes to justify buying or investing time into these tools.
This article gives some tips on managing the internal communication around sales within your ticketing system. Our primary goal here is to make sure nothing gets lost, dropped, or forgotten. Our secondary goal is to smooth out asynchronous communications between sales staff, sales engineers, front office, and technicians.
First: Sales Queue/Sales Board
Depending on your PSA or ticketing system, you should either have a queue or a board devoted to sales. Sales means everything from RFQ (request for quote) to quote, negotiation, sale, payment, or ordering the hardware and software. In other words, it’s everything that happens right up to the point where an actual service request is created so technicians can go do the work.
Whether you have a sales person or do it all yourself, it’s a good habit to have sales activity take place in the sales queue. That way the sales person doesn’t lose anything and the technicians don’t have to worry about it until they need to do something.
Second: The Flow of the Sales Process
As you define statuses that make sense for your organization, it is helpful to plot out how a prospective sale flows through your ticketing system. Here is a typical flow:
– Client requests a quote for a new desktop.
– – Technician acknowledges the service request. The ticket is placed in the Sales Queue, assigned to the sales person, and the status is changed to “Sales.”
– The sales person generates a quote and sends it to the client.
– – The ticket status is changed to “Waiting on Client.”
– The client asks for options regarding hard drive size. The sales person changes the status to “Sales” unless he is able to turn around a revised quote in short order. In either case, the status goes to “Waiting on Client” after the revised quote is produced.
– The client approves the quote.
– – The Sales person generates an invoice and puts a note in the system about what is coming.
– – The Sales person EITHER moves this quote to the appropriate service queue or create new tickets in the appropriate tech support queue. In either case, the ticket status is now “Waiting on Client.”
– Client payment is processed.
– – The front office puts a note in the ticket that payment has been received.
– – Assuming the sales person does the ordering, the status is changed to “Sales.”
– Equipment and software are ordered.
– – The ticket status is changed to “Waiting on Parts.”
– Equipment and software arrive.
– – The ticket status is changed to “Schedule This.”
Note: At this point the sales person is out of the picture, the front office staff are out of the picture, and the service ticket is now in the appropriate service queue.
Note that this flow allows all departments to “communicate” with each other through the ticketing system. At no point are two departments required to sit down and talk through all this face to face. If they get a chance (and that’s very likely), great. But nothing in this process allows the flow to get stuck just because two people couldn’t be in the same office at the same time.
At the end of this flow, the ticket is no longer in the sales queue but in a support queue (e.g., Level I). And the status is Schedule This, so the service manager knows it is ready to work on.
Migrations and Complicated Tickets
In more complex cases, a sales process might result in a series of service tickets. In this case you will definitely not covert one sales ticket into a single service ticket. For example, our migration process results in seven distinct service requests. Even a simple new office installation might result in tickets for
– Firewall configuration
– Server Build
– Server Setup
– Data Migration
– Workstation Build
– Workstation Delivery
– Printer Setup
– Testing, Documentation, Fine-Tuning
The never-ever-ever-ending rule is that you cannot lose anthing or “drop” anything. The system you design must work so that everything in the quote is entered into the system as some kind of action (order the right equipment, set it up, train the users, etc.). And the minute all items are ready for action, the status will reflect that to the tech department.
If you do have some kind of quoting module in your PSA or CRM system, I encourage you to learn that and see how well it works for you. Many of these systems have no way to convert CRM/quoting activity into service tickets. But some do, so explore that option.
Whether you implement a sales flow similar to this in your ticketing system or not, you really need to have some kind of sales flow. It should allow you to make sure quotes (and pieces of quotes) don’t get lost. It should also facilitate communication between the departments. Start by literally drawing out this flow on a piece of paper. Then create a Visio or other diagram so that you can visualize the flow. Finally, create the processes within your ticketing system to make this happen.
Ad of course you have to document your process.
– – – – –
About this Series
SOP Friday – or Standard Operating System Friday – is a series dedicated to helping small computer consulting firms develop the right
processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete “table of contents” for SOP Friday at SmallBizThoughts.com.
– – – – –
Next week’s topic: Business Cards . . . All the Details
All material Copyright (c) 2006-2012 Karl W. Palachuk unless otherwise noted.