We are running a few blog posts over time describing typical ticket configurations for different types of business, so stay tuned and you may see something relevant to you! This week we will be looking at a typical ticketing setup for ISVs (Independent Software Vendors). Please bear in mind this is only an example of how you might use Harmony; created for your convenience and reference. You will almost certainly want to customize your set up to a less or greater extent.
A typical ISV ticket configuration
ISVs typically use ticketing for three broad areas of work:
- Helpdesk - where customers call up for help or with a problem and their 'issue' needs to be tracked and resolved
- Project Work - where a customer has paid for some work to be done, and there are many tasks, features, bugs etc etc related to that work that need to be tracked
- Capital Expenditure Work - this would typically be R&D type work building on your intellectual property and usually funneled into some sort of software product sold to many customers
Using Harmony ticketing we can model all three of these types and ticket and actually make these different types of interact with each other. This is very useful!
At the heart of Harmony ticketing is the concept of Ticket Types and Workflows. We will start with the main Ticket Types you will create.
The 'Call' type of ticket
This type of ticket represents a customer facing issue. The customer has called or emailed you to let you know of a problem, concern or question.
The key aspect of this type of ticket is that is should probably be tracked against an
SLA. You can define these within Harmony to match either internal or customer contractual SLAs. SLAs are satisfied by your ticket reaching certain
Statuses in your
Workflow within specified timescales.
Also, these tickets will be tied to a customer, a contact and possibly to a contractual agreement with the customer.
A typical workflow for this type of ticket might include:
- Responded To
- Requires Development
- Awaiting Customer Feedback
You can imagine what these statuses represent, however the Requires Development status is interesting as it implies the use has created a second type of ticket, on which this ticket is dependent for closure. This would typically be a Bug or Feature type ticket.
The 'Bug' and 'Feature' types of ticket
These types of ticket are used to actually do development work and are not customer facing (ie the customer would not see this in their portal and they cannot raise them directly)
The reason that these are a separate ticket is because they have their own workflow, and a Bug may actually close a number of 'Calls' which may be with different customers.
The user responsible for the Call with the customer can see any related Bugs or Features they are waiting on to close the Call.
These Bugs and Features can be prioritised along with all other Capital Expenditure work and sent to different teams etc.
A typical Bug or Feature workflow might include the following statuses:
- Under Development
- Code Complete
- In Testing
- Scheduled For Release
Typically a Feature type workflow would include the approval steps whereas the Bug might not.
These types of tickets can be used for Project Work both before and after delivery.
The 'Release' type of ticket
A Release typically goes through a test cycle and would release a number of Bugs and Features into production. As you build up a release, you would be looking for Bugs and Features which are in a status of Code Complete, make them dependent upon the Release and change their status to In Testing.
The best part of this process is that when you close the Release, the system will close all the Bugs and Features and also any of the Calls which are dependent upon these! A real time saver!
A typical Release type ticket would include the following statuses:
- In UAT
- Awaiting Release
We hope these examples have given you some ideas. As always, we welcome any feedback or scenarios of your own. Good luck!