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.