How to use AI in customer support without creating a second incident

Support is where AI looks like free headcount and behaves like a junior who is sure they are right. The safe split is simple: machines sort and draft. People send, refund, and reset access. If you invert that, you will spend the savings on chargebacks and Twitter.

Week 1: tag the last thousand tickets

Export them. Agree five to eight tags: billing, how-to, bug, abuse, shipping, other. Few-shot a model or train a small classifier. Route. This does not talk to the customer. It is the highest-ROI step and the one vendors skip because it is not a demo.

Week 2–3: drafts from the help center, not from the void

The agent sees a draft that may only quote published articles. If no article exists, the draft says “we don’t have this written — here’s a holding reply” and you create the article that afternoon. That is how the niche gets cheaper over time. Deflection that hides missing docs is fake.

• Measure first-response time and reopen rate, not “tickets closed by bot.”
• Ban auto-send for anything involving money, data deletion, or account recovery.
• Keep the human’s edits. That is your next eval set.

Help-center search is a product

Customers will type into a box if the results are their article, not a paragraph invented from marketing. Index the real docs. Cite them. If search fails, show email. A hallucinated “yes you can cancel instantly” when your policy is 30 days is a legal and Stripe problem.

Macros still beat magic

For the ten questions that are 40% of volume, a saved reply with a merge field is faster than a model and never invents a policy. Use AI for the long tail. Use macros for the head. This is not old-fashioned. This is operations.

How I judge whether the idea is real

I ask three questions on the first call. What job did a person do last week that you want a machine to draft? Who checks the output before a customer sees it? What happens on Friday if we turn the feature off? If you cannot answer those, we are not ready to write a statement of work. We are ready to write the FAQ or the SOP first — and that is often the actual project.

I would rather decline a fashionable chatbot than ship something that lies about hours, stock, refunds or a diagnosis. The invoice has my company’s name on it. That is why the no’s are part of the work.

What you should have in writing before you pay anyone

The job in one sentence. The data the model may see. The human who confirms. The metric you will look at in 30 days. The kill switch. The legal name of the vendor. USD price and when the card is charged. Who owns the repo. If a vendor cannot put those on one page, you are buying a demo.

• Nothing is billed by us before you approve a written scope.
• Typical project billing is 50% to start and 50% on delivery, through Stripe.
• Code, design and prompts we write for you transfer on final payment.

The steps — do these in order

1. 01

   Export a thousand tickets and agree the tags

   Five to eight buckets. If you cannot tag them by hand, a model cannot either.

2. 02

   Route before you generate

   Billing, how-to, bug, shipping. This step does not talk to customers and still saves the most time.

3. 03

   Write the ten macros that are 40% of volume

   Saved replies beat a model on the head of the distribution. Use AI for the tail.

4. 04

   Draft only from published help articles

   If the article does not exist, write it that afternoon. Do not hallucinate policy.

5. 05

   Ban auto-send on money and access

   Refunds, deletions, password resets stay human until you have logs you would show Stripe.

6. 06

   Measure reopen rate, not bot-close rate

   Deflection that hides angry people is an incident with a delay.

7. 07

   Keep the human edits

   That corpus is next month’s eval set.

8. 08

   Publish the cancellation and refund rules on the site

   Support AI that contradicts the legal page will lose you the argument.

Keep reading

• Think. Build. Ship.

  Think. Build. Ship. — the only order that produces a product

  Think is understand the problem. Build is engineer the solution. Ship is put it into the real world. Skip one and you have a tutorial, a file, or a pitch — not a product.

• Tutorials

  Tutorials are not a product. A link is.

  You can finish a hundred tutorials and still have nothing to send. Shipping is a link that does a job — that is what SINLE Academy is for.

• Bootcamp

  SINLE Academy is not a coding bootcamp

  No job promise. No certificate as the product. Eight people, six weeks, $400 — you leave with work someone can use, not a placement story.