Since I’ve helped set up hundreds of OneDesk accounts by now, I am frequently asked by customers and other members of our team, what are some ‘best practices’ that should be followed to ensure customer success. Since I am always glad to share my wisdom 🙂 I thought it could be useful to write up a blog post that covers some lessons learned.
1) Importing a list of customers is often unnecessary
OneDesk supports the ability to import your customer list as well as your existing tickets. If you want to do this go ahead, but here are two considerations.
– OneDesk will automatically create customer records for you whenever it receives an email from a new email address. This means that you can just let the customer records accumulate as your customers submit tickets.
– If you are planning on importing existing tickets, make sure you import your customers FIRST. This is because when the import process creates a ticket, it can link it to an existing customer record (as long as the email address of the requester is in a column in the ticket-file).
2) Don’t make a task, when a workflow status will suffice
This recommendation depends on the situation, but when you have a series of steps that a task must go through, and those steps are mutually-exclusive, then a status is the way to go. Sometimes there is a temptation to create a list of tasks which could instead be represented as a single task with different statuses. Something to think on.
3) Give your users the highest level of project-permissions that you can.
OneDesk gives you some pretty powerful permissions controls both at the organization level and at the project level. This is because a user may be permitted to do certain things in one project, but not in another. However, I recommend that for project-level permissions, you give everyone the highest level you are comfortable with (This means ‘project manager’ or ‘project lead’). If you don’t then be prepared to field questions from your users on why then can’t do something, and spending time modifying individual permissions in individual projects.
5) Use types wisely
When users discover our amazing types system they often go nuts and create types of items and projects for all their cases. This is probably not the best approach.
– You should only create a new item type when you require a different workflow. For example, if an ‘issue’ goes thorough different steps than a ‘task’ then by all means create a new item-type. However, if both go through the same steps, then you are adding complexity just to have a different icon.
– Having different types of projects is usually unnecessary. Having different types of portfolios almost always unnecessary. The above rule for items applies to projects and portfolios as well, but with the added points that projects are even less likely to have different workflows, and portfolios don’t even have workflow capabilities.
6) Linking new items to existing items can get confusing fast.
Some processes require that one item (for example a ‘task’) be created-from or linked-to an existing item (for example a ‘ticket’). OneDesk allows you to do this, but I don’t recommend it if you can avoid it. Instead you should change the item type to the new type (eg. from ticket to task). The reason to avoid linking is that unless you impose strong policies at your company, before long you will have a bunch of things linked in a crazy graph. Firstly this is impossible to hold in your head and reason about, and secondly untangling it and ensuring that all loose ends are accounted for is a hassle.
7) Don’t merge tickets, instead use bulk-tools & macros
I am often asked about the ability to merge similar tickets into one ticket. OneDesk does not support this, nor do we recommend this. Here’s why. For each ticket you receive there is specific individual info on it that is unique to it. This could be differing details or descriptions which can be useful later. There will also be conversations, contact information and more. You don’t want to risk losing information in a merge, not do you just want to copy it all across. Instead place these tickets in a common folder and when it comes time to update them or respond to them, use the bulk-change or macros features.