Ticket lifecycle and communication with Clients in Helpdesk
Introduction
In this article, we will go over ticketing process depending on the way a ticket is created in Help desk and according to the client's access into your system. You will find tips about what to look out for in various ticket process configurations.
This article contains tips and suggestions for various configurations, but not directly how the configurations are made. Here are the relevant articles:
- Help Desk documentation
- Owner's manual (workflow, notification settings)
Three main communication routes
Starting with a scheme of ticket lifecycle in straight forward situations - when the ticket follows just one type of flow from start to finish.
- Full user in application
- Help desk user in application
Creation and further communication within a ticket
Ticket creation and further communication can combine the above approaches.
It is possible to create a ticket via email and then follow up in the application (whether by full user, or help desk user). It is also possible to create a ticket via the system and then only follow emails.
Example 1
- Tickets are created via email - the client sends a new email to the helpdesk address.
- The client logs into the system and can see the ticket there, as he is the ticket author.
- Clients may change statuses and other fields as well as leave comments, according to their permissions.
Example 2
- The client logs into the system and creates a new ticket.
- Client receives updates via email and only watches these updates and does not feel the need to log in to the system anymore.
Example 3
- Client creates a ticket via the helpdesk portal
- Client decides he wants to follow only emails and no longer logs into the portal
- The client then decides that he wants to follow via the portal, logs I and enters some replies via the portal.
For the sake of your Clients' convenience, you can decide by which methods you want to allow them to create and/or update tickets. But most importantly, you need to cover every possible situation, so that tickets will not get lost into a dead end. Workflow and other configurations provide all the necessary options.
Common issues
Client replies to regular task notification, but the reply is not processed properly.
This story concerns Example 2. Clients think they are replying to a ticket via email, but the email is not paired with the existing ticket and instead a new one is created, or the email does not reach the system at all. Client replies to a notification, or by mistake creates a new email.
The cause: Email notification settings do not expect replies to the notification address.
Solution: Clients response needs to be sent to a helpdesk specified address and needs to contain the ticket number. Notifications email address (Administration >> Settings >> Email notifications >> Notification email address (FROM)) maybe the same as a helpdesk mail address to catch any replies from clients and pair them with the ticket from which the notification was initially sent.
Another option is to simply disable regular email notifications to the client users. The only emails from tickets they would receive would be actively sent by the operators via help desk email templates.
Key takeway: Your clients will be naturally tempted to reply to any email messages they receive. Make sure that they receive only messages to which replies can be processed properly.
Client changed ticket to "incorrect"status
This mostly occurs in situations when the client has a full user in the application (instead of Help desk user). Client may have the option to edit many fields, including status and may misinterpret the meaning of various statuses. Or on the other hand may not change the status, when you expect it to be changed.
The cause: The client is made responsible for setting correct status.
Solution: This is a clear anti-pattern, the client should not have to remember any rules for task statuses.
One solution is to switch clients account to Help desk users, instead of full users. Help desk users can create tickets and enter comments into existing tickets, status changes are based on Help desk configurations, so there is no chance that the client will "break" some correct process. Help desk users' ticket updates are practically designed to follow the help desk email communication logic and settings. The only difference is that the user can actually see and work with a physical form of the ticket.
If you need to keep the full users for your clients, our suggestion is to completely disable any status changes (or other fields changes), which may break some of your internal processes. Use other ways to track tickets that need to be updated - for example by field Task last updated (date of last update), Last updated by (who made the last update), you can show the last comment on a ticket in the list, so that it is clear the a client made the update.
A slightly more complicated scenario is from Example 1, when you allow ticket communication via email, but also allow clients to log in by full user. Here is what to look out for:
- Status change after client replies by email is set in global help desk settings
- There is no status change enforcement for logged in users - there is always the option keep status as is
In this case, you should make sure that your queues for response contain both types of situation, updated by email (e.g. filter for a specific status), and tickets updated by clients from within the application (e.g. ticket list wtih column Last comment).
Key takeway: Client should never worry about your internal processes, they just need a place to submit their troubles and communicate with you, the processes are on you and the application has various options to set it tight.
Mixing full users and help desk users
This is just a strong warning not to combine solutions which were never meant to be combined. You can decide whether to use
- Help desk users - free of charge, with hardcoded limited access, or
- Full users - regular licenced users, where you decide what they have access to
, but you should not use both at the same time, especially for the same clients. Technically, full user and Help desk users are not in any way connected. They even have a different login page. They represent a different field on tasks (author vs help desk author). So there is no reason to confuse your client by providing them both access options.
As for your internal processes, it is technically possible to provide some clients full users, and to others just help desk users. However, this requires precise process descriptions and trainings for your agents to ensure they will not mix up processing of tickets from these very different channels. Due to its organizational difficulty, we strongly recommend to only choose one option for client access.
Summary
Let us put the previous information back to a digestable form. Here is a table of situations that may occur based on type of access of your clients to your system.
| Client access into application | Options to submit ticket (client) |
Notifications from ticket (agent) |
Options to update ticket (client) |
Our recommendations |
| Without access | Send email to a helpdesk email address. | Agent sends email via template from the ticket. |
|
|
| Full user |
|
|
|
|
| Help desk user |
|
Agent sends email via template from the ticket. |
|
|
