Lectures Learned From Customer Service Management Experiences

Over the past t two decades, we have learned two main lessons from customer service management experiences.

12 February 2019

Helpdesk (Ticketing) Is Not Enough.

In short, within a typical ticketing based help desk, you collect an issue, forward it to the related people via e-mail and then await for an answer. Hopefully by then, an answer comes by and then you can return back to the customer. You can track an issue only through its status such as “new”, “in-progress”, “resolved” etc.

There are a hundred types of ticketing solutions. But our claim is that ticketing based help desk solutions result in fragmented customer service. That is to say that when an issue requires the contribution of other units, partners, suppliers etc. it is mostly done by emailing the issue to the related people or submitting it upon another system. But customer service departments are in charge of whole resolution processes. And this is because customers are waiting for answers from customer services.

Problems of Fragmented Customer Service

  • Using emails as a workflow tool: After you have an issue, you forward it to the related people or units by email. In this case, if you or your customer want to hear about the issue, you should call the related people or ask via email. You only have an “in-progress” status at hand during the whole resolution process. You have no single tool for monitoring what is being conducted on which issue.
  • Using other systems as a workflow tool: After capturing the issue, instead of forwarding an email, if you submit the issue to another system to be tracked, then this means that the fragmentation of the issue life cycle and you have to track it in two different systems. If you would like to receive a report about the full issue life cycle (for example which units were late, which ones were on time, who was doing what on an issue) then you have to combine the data in both systems to formulate a single report.

Different type of issues requires different types of resolution processes.

  • For each type of issue, you need to ask different sorts of questions while capturing the issue.

Different forms for different types of issues

For example, the process to resolve “bad employee behavior” type of issues is completely different when compared to issues of “late delivery”. When addressing the first process, while capturing the issue you also need to ask the customer the name of the store, where and when the “bad behavior” occurred and what the “bad behavior” was. In the case of “late delivery”, you may need to ask the customer their order number while capturing the issue.

  • For each type of issue, different units should be involved in the resolution sequence with different service durations

Different workflows for different types of issues

In the “bad employee behavior” type of issues, you may request from the related store a report about the case and in the next step, you may ask HR to come with a decision.

In the “late delivery case”, you may ask the operations department the shipment details and you may also request the delivery data from the logistic company and so on.

However,  if you are using a ticketing solution, you have only one flow which is; forward it to the relevant unit which you think should be in charge and you can track only the status of the issue.

Untrackable, unmeasurable Secret Box “in-progress”

It should be noted that being aware of the status of an issue is not enough. We need to reveal the secret box, we need to know more about what is really progressing within “in-progress”.

Forwarding the issue and asking what is happening in the resolution will slow down the customer service experience and may even lead to an unhappy customer. Issue management is, therefore, process management.

Single view of issue life cycle

For each type of issue, we need to design the resolution process:

  • What will be the resolution workflow steps?
  • Who will be incorporated within each step?
  • What will be the actions within each step?
  • What should the service levels be?

Only process-based customer service management provides:

  • Performance KPIs: Who is late? Who is on time? What are the service levels of partners, suppliers?
  • “End to End” Issue Tracking: A single view of an issue life cycle. Who is doing what on an issue? What should the person in charge do, what were the previous actions, what will be the subsequent actions?
  • Improvement opportunities: How can we improve the processes for better customer satisfaction and for reducing issue resolution costs.

No IT Then No Cry

Whatever established software you have, how much it meets your current requirements, or how user-friendly it is; it doesn’t really matter too much. Every software will have to be modified in order to adapt to changing requirements.

However, IT departments usually have long pending task lists and hectic schedules. Whenever you have a change request for them, they will most probably prompt you towards their resource and budget planning. You will find yourself in a situation where you need to explain why you need the changes, the expected return value from this change etc. Imagine you convinced IT to schedule your requests but then you will have to deal with man-day budgets, project plans, delivery dates, delays, postponements etc. Overall when you get the changed implementations it may be too late.

On the other hand, from  IT’s perspective, never-ending change requests and wish lists must be planned in an appropriate way. Therefore, software solutions that reduce the IT dependency, would be the choice of IT departments also.

Beyond Flexibility

You will need a flexible software that will let you reduce the business unit’s IT dependency. Namely, the business units should be able to design and modify workflows and forms on their own.

In Mi4biz administration interfaces, you can define or change, category structure, customer issue types, communication channels, issue root causes, departments, regional working hours, …. in short, every parameter to customize Mi4biz for your own needs.

Moreover, Mi4biz provides design editors that business units can design or change forms and workflows by themselves without any technical assistance. Our customers have been doing it for years.

For instance, in the diagram below, a request arises to add a multiple-choice box field into the “late delivery” issue form.

A new field (logistic company) has been added without writing any line of code.

In another example below, a new workflow step is added to process design. Needless to say, you can also change SLA or escalation scheme without writing codes!

This example workflow can be easily edited from two steps to there or more steps.

A new unit has been added to the “Personal Behaviour” resolution workflow within a couple of minutes.

A Comparision Between Traditional and Non-Code Solution (Mi4biz)

The diagram below compares the delivery and ongoing costs of implementing and maintaining customer service management solutions.

The vertical and horizontal lines represent the cost and time dimensions. In Mi4biz’s software, delivery duration and delivery costs are far fewer compared to those in traditional cases.

But what will be the cost after delivery?

As a result of changing requirements, sometimes you will need to add a new field on an issue form. You will discover more efficient ways of resolving issues. You will need to improve your workflows or processes. Sometimes you may change the agent scripts based on your agents’ experiences. Mi4biz is a no-code solution, you can design new processes or customize the current ones without the need for any technical assistance.