AI in customer messages, carefully
Sort the queue before automating any of it. Drafting is not sending, and the policy you have not written down is the one the tool will invent for you.
Customer messages are the most tempting thing to automate and the easiest to get wrong, because the cost of a bad answer is not a bad answer. It is a person who now trusts you less and tells somebody.
Sort the messages before automating anything
Support volume is not one queue. Separating it is what makes the decision obvious, because the right amount of automation is different for each kind.
- Where is my thing. Order status, access, receipts. The answer is in a system and the customer should be able to see it without writing to anyone. Automate this out of existence rather than answering it faster.
- The product did not explain something. A real answer exists and is the same every time. Safe to draft automatically, and the recurring ones should be fixed in the product.
- This person's situation is unusual. Needs judgement and often needs you. Automating this is where the damage happens.
- Something has gone wrong and they are upset. A person, always. Nobody has ever been calmed down by a fast reply that missed the point.
What a drafting setup needs to be any good
- Give it your actual answers. The previous replies you were happy with, the product documentation, the refund policy as written. Without these it invents a policy, and an invented policy you accidentally send becomes your policy.
- Give it the specific facts for this customer, or none. A draft that guesses an order date is worse than one that leaves a gap for you to fill.
- Tell it to say it does not know rather than to produce something. Then make not knowing an acceptable outcome for yourself too.
- Read every draft before sending, and keep doing it. The day you stop is the day it sends something you would not have.
The policy question nobody asks first
Before any of this: what does the thing say when a customer asks for something your policy does not allow? If you have not decided, the tool will decide for you, generously, in writing, to a customer who will then hold you to it. Write the refund rule, the exception rule and the escalation rule down before you automate the first reply. Those three sentences are the actual project.
If you do put something in front of customers
- Say it is automated. People are reasonable about a machine and unreasonable about being deceived by one.
- Make reaching a person obvious and quick, on every screen, without a maze. Google's own publisher rules treat dead-end screens as a problem, and a support flow with no exit is the same failure.
- Scope it narrowly. A thing that answers five questions well beats one that attempts everything and is wrong about the sixth.
- Never let it make commitments. No promises about delivery, refunds, prices or dates.
- Read the logs weekly. What people ask is the most honest product research you will ever get, and it is free.
Two things are worth adding because they are easy to forget. Anything a customer types goes to a third party when you use a hosted model, which belongs in your privacy policy and may need their consent. And a reply in the wrong language is worse than a slow one, so if you serve several countries, check the behaviour in each.
Work to do
- Sort last month's messages into the four kinds above and count them. The largest group tells you what to build first, and it is usually the one that should be automated away rather than answered.
- Write the refund rule, the exception rule and the escalation rule in three sentences, before touching any tool.
- Set up drafting rather than sending, and keep reading every draft for a month before deciding anything else.