154 lines
6.7 KiB
Markdown
154 lines
6.7 KiB
Markdown
title: An alternative to annoying phone hotlines
|
|
---
|
|
pub_date: 2020-11-29
|
|
---
|
|
author: Nico Schottelius
|
|
---
|
|
twitter_handle: NicoSchottelius
|
|
---
|
|
_hidden: no
|
|
---
|
|
_discoverable: yes
|
|
---
|
|
abstract:
|
|
Making technologies improve our life
|
|
---
|
|
body:
|
|
|
|
## The phone hotline
|
|
|
|
If you have a problem with your contract, if you want to have some
|
|
information about your product or you just want to change some
|
|
detail. By default, many companies nowadays offer something that we
|
|
call "hotline". Or in other words: a voice based communication that
|
|
allows to easily queue people.
|
|
|
|
The motivation and how it works is rather clear: there are a finite
|
|
number of employees, each of which can only talk to one person at a
|
|
time. So if the number of requests is more than number of employees,
|
|
then you are stuck in the queue. However this post is not about the
|
|
annoyance of waiting in a queue and enduring little quality, down
|
|
sampled classic music pieces.
|
|
|
|
No, in this post I want to address a different fundamental problem:
|
|
every time you call, you start a fresh conversation. You are likely to
|
|
talk to a different person with a different background and probably
|
|
not much knowledge of your situation. From a customer perspective you
|
|
usually don't have any trail of previous communication. Actually, the
|
|
company you are calling might record (and correctly announce it
|
|
before) the call. However as a customer, you cannot easily record as
|
|
well. Often it is also impossible to correspond with the company by
|
|
email, so all written communication has to be sent in letters. In
|
|
2020!
|
|
|
|
Looking at it this way clearly shows how much power imbalance the
|
|
innovation of the phone hotline is causing. But it could easily be
|
|
different.
|
|
|
|
|
|
## The classic way
|
|
|
|
You might or might not remember when companies used to be smaller and
|
|
you would request a service with the counterpart in person. Both of
|
|
you know each other and are fully aware of each other responsibilities
|
|
("I give you money, you give me a product or service") and also of the
|
|
support process (A: "It did not work" - B: "I'll fix it!).
|
|
Often the service provider was not far away, might even have been my
|
|
neighbour. And it's really not good for our relationship if my
|
|
neighbour does do what he promised to do.
|
|
|
|
As you can easily imagine this does not scale nor work easily in big
|
|
companies where staff is rotated or fluctuating. The old value system
|
|
of being responsible on a personal basis cannot easily be
|
|
transferred. This also means that the classic way is much more
|
|
expensive in terms of time and resources, but the responsibilities are
|
|
enforced by social relationships.
|
|
|
|
## Mixing the two?
|
|
|
|
So we could say that they are two extremes: one very personal, high
|
|
quality, expensive and the other - well, you get the picture. Is it
|
|
possible to improve the current situation and how can we get the best
|
|
of the two worlds? Before answering this question, let me give you a
|
|
short background of where we, ungleich, are and how we work, to show
|
|
you how these approaches can naturally merge.
|
|
|
|
|
|
## ungleich @ Digital Glarus
|
|
|
|
ungleich is based in [Digital Glarus](/u/projects/digital-glarus/),
|
|
a really old mountain valley in Switzerland. Majority of its buildings
|
|
are very old (I'd guess most are built prior to 1900, many even much
|
|
older), major businesses are industry, farming and also tourism. Many
|
|
people here get up before 6 and start working latest by 8.
|
|
|
|
We from ungleich on the other hand are working in IPv6 only
|
|
networks connected by our own fiber or with long range wifi links. Our
|
|
working hours are very flexible, can be morning, day, night, week,
|
|
weekend - we are free to choose. Our topics are very technical by
|
|
nature.
|
|
|
|
These two approaches can contradict, but they can also work together
|
|
very well. Like the two ways of communication.
|
|
|
|
Interestingly our experience here is that they can easily be combined:
|
|
many people living in Digital Glarus have what we call an "old value
|
|
system". If you offer a service towards people in Digital Glarus, you
|
|
need to take responsibility and be trustworthy. Otherwise the word
|
|
will get out within a few days and social enforcement will result in
|
|
no more work for you.
|
|
While this might sound cruel, you could actually call this "social
|
|
quality assurance". Actually a bit similar to what we see in social
|
|
media, just lower scale.
|
|
|
|
And how does this look like in reality? People here want and need to
|
|
be convinced that you are trustworthy. You are having in
|
|
person meetings (before corona), one person will make a protocol and then later send
|
|
it for verification back to the other party. If something is noted
|
|
incorrectly, the protocol will be amended and again verified.
|
|
|
|
This ensures that trust is built and also that both parties, the
|
|
delivering company as well as the customer are playing on eye level.
|
|
|
|
## Combining old values and new communication
|
|
|
|
Let's come back to the original problem: we shifted from high quality,
|
|
individual services to mass produced in-transparent
|
|
communication. Technically and organisational, it is not necessary to
|
|
provide a worse product or service if it is mass produced. It just
|
|
happens to be the case due to technical limitations in the beginning.
|
|
|
|
So let's go back to the hotline problem: we advocate a simple change
|
|
that costs little for companies to implement but restores trust and
|
|
quality in communication:
|
|
|
|
**Every support hotline should be, by default, accompanied by a text based
|
|
ticketing system that sends users a protocol and let's them interact
|
|
with you on a text basis.**
|
|
|
|
So how does this work? The agent in the call center will make notes of
|
|
the phone call - they are already done nowadays, but unavailable for
|
|
you. Some of these notes might be internal ("The customer does not
|
|
know the difference between the power button and the reset button -
|
|
always advise to push the button on the right") and are not for
|
|
sharing. However, **the key points of the conversation must be sent to
|
|
the customer**. This way, as a customer I can easily react and correct
|
|
statements that have been incorrectly recorded. With a trail.
|
|
|
|
Furthermore in a later stage, as a customer, I also have a trail and
|
|
the ability to respond to the previous conversation by text, giving me
|
|
the opportunity to add to the trail. And to built trust on the way.
|
|
|
|
Obviously, our suggestion here is not rocket science. In fact, it is a
|
|
very easy, natural and cost effective measure to be more transparent
|
|
and to built mutual trust.
|
|
|
|
Some companies might try to argue that it is too complex or too
|
|
expensive to implement such a system. To prevent that argument from
|
|
being true, we have added a [Hosted Support
|
|
System](/u/products/hosted-support-system/) to our product
|
|
list. Nobody needs to get it from us, but anybody can. And thus there
|
|
is no excuse, not to have it implemented. It is a very similar
|
|
[approach to not have an excuse for not having
|
|
IPv6](/u/products/ipv6-vpn/), but that is a story for
|
|
another day...
|