Oki-Toki is a cloud service for call centers, packed with numerous features for work process organization, report building, and tailoring settings to various business ideas. Due to its extensive functionality, there is a vital need for competent technical support that is always, and most importantly, timely to answer questions and find problem solutions. This article is exactly about that – how the ticket system for handling customer queries is managed in Oki-Toki.
Our ticket system has been in place for over two years. The first ticket from a client was created in July 2018. Since then, we have been testing, observing, and adding tools for customer convenience when working with tickets and monitoring the quality of our support team’s work. We did this for ourselves and for the first time, so improvements were made as we realized the need for them.
This article pertains to the product “Cloud call center“.
Problems we wanted to solve at the start
- Lack of processing customer requests. This was our main issue, to solve which we developed a ticket system. At that time, we used only Skype for communication with clients, which meant that all complaints, inquiries, and suggestions were written in “General Chats”. A significant part of these messages “got lost” under later chats.
- Absence of personal liability for resolving a client’s issue. This situation invariably led to instances where our agents could ignore the request, hoping someone else would take care of it.
- Difficulty in monitoring the problem resolution process. Why keep a track of the situation when the client will eventually remind us themselves?
- When operating through Skype, the contribution of individual agents, as well as the overall effectiveness of the technical support, was challenging to assess.
In summary, these are not unique problems; they’re well-known and widely experienced. Their solution boils down to the implementation of two tools: ticket management and monitoring of effectiveness, amidst a flurry of extras and bells and whistles.
- The client creates a ticket, selects the type of request, and closes it themselves if the offered solution suits their needs.
- The support agent and the client correspond in chat and document ticket status changes. Each party has its own permissible statuses. Support can set ‘Awaiting data’ (when additional client information is needed to solve the problem), ‘Postponed’ (with a pause timer for ticket work), ‘In development’ (if programmer involvement is required. In this case, the status is accompanied with the selection of an engineer, task number in Jira, and an execution deadline.
Monitoring the efficiency of the support service
- Preparation and email distribution of daily/monthly reports:
- Statistics on created and closed tickets for the period
- Data on ticket interactions: average number of messages per ticket and average message length, grouped by agents
- Summary table on ticket statuses and agents
- Summary report on rejected solutions in tickets (grouped by companies and responsible agents)
- Top companies by tickets and types (problem/consultation/idea)
- Average duration of statuses in tickets grouped by responsible agents
- Alerts (number of disciplinary infractions related to statuses for each user)
- Number of ratings (likes/dislikes) on messages in tickets
- List of ‘In Development’ tickets which delivery was postponed more than once.
- Disciplinary standards – alerts. For each status in ‘Ticket Timeouts’, a timer has been created with intervals (from one to three). They correspond to the degree of disciplinary violation. The summary table of violations in the regular report reflects the type, number and degree of regulatory violations during ticket processing.
- Flexible personal work schedule of the support team. They are the basis for alerts of disciplinary violations, as well as automatic ticket distribution.
- Ticket system and KPIs. For example, over a month, the share of rejected solutions for a support agent should not exceed 20% (i.e., no more than 1 rejection for 5 proposed solutions)
- Reactions (likes, dislikes), ticket ratings and the ability to leave feedback
- The system can automatically assign a ticket to a free agent or change the responsible if the previous tech support agent “forgot” about the ticket and violated the discipline limit for processing ticket statuses;
- Convenient set of filters and a form for searching any active ticket;
- Hidden messages in the ticket – useful for discussions and notes within tech support;
- Two types of interaction with Telegram:
- dissemination of information about new tickets and changes in existing ones (for tech support agents)
- messages about tickets with low ratings, negative reactions or disciplinary alerts, ticket-system for executives
- Notifications or “Broadcast” – global messages about breakdowns, implementations and planned works
- According to customer reviews in work chats and review services, Oki-Toki’s technical support ranks in the top 3 main advantages of Oki-Toki.
- We realized which clients require a comprehensive approach in terms of solving complex issues.
- Based on the data we have received, we can now assess which section of the system needs more attention.
- “Is the support agent trying his best or just pretending?”. This is a question I no longer ask myself: everything is on paper, in numbers and percentages. Moreover, it has become easier to calculate the need for agents, reward for success, or rebuke for its lack.
- About Oki-Toki ticketing system you can read in another article.
- In the near future, the Oki-Toki ticketing system will be updated into our new product “Chats“, which will expand the possibilities of communication with tech support.
What did we get?
I can now say that we are pleased with what we have achieved. Flexibility, functionality, control, autonomy – the qualities that technical support always lacked and which management desired. Of course, this is not the final version – we have a list of ideas, large and small, on which we are actively working, but all critically important ideas have already been implemented.