Sales chat gets all the attention. The visitor who might buy, the lead captured at 10pm, the conversion rate. Meanwhile the support inbox fills up with people who already paid you: how do I reset this, where is my invoice, is this covered under warranty.
Those customers matter more than their volume suggests. They are the ones who renew, reorder and recommend you. They are also the ones who get most annoyed by a slow or wrong answer, because they feel you owe them.
An AI support assistant for existing customers needs a different mindset from a sales assistant. The goal is not to capture anyone. It is to answer what can be answered from documentation, and to recognise quickly when a question needs a person and a record.
Three groups of post-sale question
Almost everything existing customers ask falls into one of three buckets. The handling is different for each, so it is worth being clear about them before you write any instructions.
How-to questions. "How do I change the filter?" "Where do I find the export button?" "What does the orange light mean?" These have one correct answer that applies to everyone and is, or should be, written down somewhere. They are ideal territory for an assistant.
Account questions. "Can I change my delivery address?" "Why was I charged twice?" "Can you resend my invoice?" These are about one specific customer's records. A website assistant answering from your content cannot see those records, and it should not pretend to.
Warranty and fault questions. "It stopped working after four months, is that covered?" These combine the two. The policy is general and can be explained. Whether this particular case qualifies is a decision for a person.
Answer, ticket or person: a decision table
This is the table to agree with your team before launch. Adjust the rows to your business.
| Situation | Assistant answers? | Opens ticket? | Hands to a person now? |
|---|---|---|---|
| How-to with a documented answer | Yes | No | No |
| How-to, no documented answer | Says it has no answer | Yes | If someone is on duty |
| Change to an order or account | Explains the process | Yes | No |
| Billing dispute or double charge | Acknowledges, no detail | Yes | If someone is on duty |
| Warranty question, general | Explains the policy | No | No |
| Warranty claim for a specific item | Explains the policy | Yes | No |
| Safety concern with a product | Gives any documented safety step | Yes | Yes, flagged urgent |
| Customer is angry or upset | Acknowledges calmly | Yes | Yes |
The pattern: general knowledge gets answered, anything specific to one customer becomes a ticket, and anything urgent or emotional goes to a human as well. When a chatbot should hand over to a human goes further into triggers.
What a good ticket hand-off sounds like
The worst version of a ticket is a dead end: "I've logged your issue." No number, no timescale, nothing to hold on to. The customer comes back tomorrow and starts again. A good hand-off collects what the team needs and tells the customer exactly what happens next.
Customer: My blender stopped working. I bought it in March. Is that covered?
Assistant: Sorry to hear that. Our blenders have a two-year warranty covering faults in normal home use, so a March purchase is well within that period. Whether a particular fault is covered is decided by the service team once they've looked at the details. I can open a support ticket for you now. Could you tell me your order number or the email you ordered with, and briefly what happens when you switch it on?
Customer: Order 48213. It makes a humming noise but the blades don't turn.
Assistant: Thanks. I've opened ticket #1047 with those details. The service team replies to warranty tickets by email within two working days, and they may ask for a photo of the serial plate on the base. Please don't open the motor housing in the meantime, as that can affect the warranty.
The warranty length, reply time and safety note all come from content the business supplied. Everything specific, the order number and the symptom, went into the ticket for a person to judge. Support tickets from chat covers setting up the ticket action and inbox.
The documentation you need first
A support assistant is only as good as the help content behind it. Most small businesses discover their documentation is thinner than they thought. Before launch, gather:
- Setup and usage guides. Manuals, quick-start sheets, help articles. Upload PDFs directly if that is where they live.
- Your top twenty support emails. Write the answers your team actually sends as Q&A pairs. These are usually better than the official manual.
- Policies in full. Warranty, returns, refunds, cancellation, with the real timescales.
- Known issues and fixes. The "have you tried turning it off at the wall" list your team knows by heart.
Building a support knowledge base your chatbot can use is a good companion for this stage.
Where to put it, and how to staff it
A support assistant belongs where existing customers look for help: the help or support page, the contact page, any customer login area, order confirmation emails that link back to the site. It rarely belongs on the homepage as the first thing a new visitor sees.
On staffing, decide who works the ticket inbox and how quickly. An assistant that opens tickets faster than anyone answers them just moves the backlog somewhere new. If a team member marks themselves on duty, they can take over live conversations from the inbox during working hours, which is useful for the angry and urgent rows in the table. On SpideyChat, the support ticket inbox is part of the Pro plan; check pricing for what fits your volume.
Getting started
Pull last month's support emails and sort them into the three groups: how-to, account, warranty. Count each pile. The how-to pile tells you how much the assistant could answer outright, and whether your documentation covers it. The other two piles tell you how many tickets to expect.
Then write your version of the decision table, get the people who answer support to agree with it, and add the assistant to your help page first.