A customer opens the chat on a Sunday evening: the online order they placed on Thursday was charged twice. The assistant cannot refund anything, and it should not pretend otherwise. What it can do is make sure the problem is written down properly, give the customer a reference, and put the issue in front of the right person first thing on Monday.
That is what chatbot support tickets are for. Not every conversation needs one. Most do not. But for the conversations where someone has to do something, a numbered ticket turns "I told the chat about it" into a tracked piece of work that does not depend on anyone remembering.
This post covers when to open one, what should be in it, and how customers find out what is happening next.
Answer, lead, handover or ticket
The first design decision is which conversations should become tickets at all. Getting this wrong fills your inbox with noise or, worse, sends real problems nowhere.
| Situation | Best outcome | Why |
|---|---|---|
| "What time do you close on Saturday?" | Answer from the knowledge base | Nothing for a person to do |
| "Can you quote for a new kitchen?" | Capture a lead | Sales, not support |
| "I was charged twice for order 4471" | Open a ticket | Someone must investigate and act |
| "The part you sent doesn't fit my model" | Open a ticket | Needs checking against the order |
| "I'm really unhappy and want to speak to someone now" | Transfer to a person if one is on duty, otherwise open a ticket | Emotion first, record second |
| "How do I reset my account password?" | Answer, if the steps are in your content | A ticket here just slows the customer down |
| "Your website checkout keeps failing" | Open a ticket | A fault that may affect other customers |
A good rule of thumb: if solving it needs someone to look at an account, an order or a system, it is a ticket. If it needs a salesperson, it is a lead. If the answer is already written down, it is neither.
In SpideyChat, opening a support ticket is an action you switch on per assistant, and it is off by default. The ticket inbox that holds them is part of the Pro plan.
What a useful ticket contains
When the assistant opens a ticket, it records a subject, the details of the problem, the customer's name and email where given, and a priority. The quality of those fields decides how much back-and-forth your team needs later.
Here is the same problem recorded two ways.
| Field | Unhelpful ticket | Helpful ticket |
|---|---|---|
| Subject | Problem with order | Charged twice for order 4471 |
| Details | Customer says there is an issue with payment | Customer placed order 4471 on Thursday evening. Their bank shows two identical charges of £64.20. They have not received a refund or any email about it. |
| Name | (blank) | Tom Reid |
| (blank) | tom.reid@example.com | |
| Priority | Urgent | High |
The helpful version lets whoever picks it up start work immediately. The unhelpful one guarantees an email asking for everything again.
You shape this through the assistant's instructions. Tell it which details matter for your common problems: an order number for shops, a property address for trades, a booking date for clinics and salons. Tell it to ask for an email address before opening the ticket, because a ticket nobody can reply to is only half useful.
Priority that means something
The assistant can mark tickets low, normal, high or urgent. The temptation is to let everything be urgent, because every customer feels their problem is. Resist that.
- Urgent is for a customer who is blocked right now or losing money: can't access a service they paid for, a fault causing damage, a payment error preventing an order.
- High is for problems that matter and should be looked at the next working morning, such as a duplicate charge already made.
- Normal covers most issues: a wrong item, a question about an invoice, a fault that is annoying but not stopping anything.
- Low suits requests that can wait, such as updating account details or a minor website typo.
Write those definitions, in your own words and with examples from your business, into the assistant's instructions. Then check a week's tickets to see whether the labels match what you would have chosen.
Keeping the customer informed
A ticket number is a small promise. The customer now expects someone to come back to them, and they have a reference to quote when they chase.
Once the ticket is open, the assistant gives the customer the number in the chat. If they provided an email address, they also receive a confirmation email with that number, and the business owner is emailed about the new ticket. If the customer replies to their confirmation, the reply comes to you, so there is a natural thread for updates.
Tickets move through four statuses in the inbox: open, pending, resolved and closed. Updating the customer is still a human job. A simple routine works for most small teams:
- Check the ticket inbox at set times, such as first thing and after lunch.
- Reply to every new ticket within your stated time, even if only to say you are looking into it.
- Mark tickets pending when you are waiting on the customer or a supplier.
- Resolve with a short summary of what was done, so the history makes sense later.
Tell the assistant what reply time to promise. "Our team will reply by email within one working day" is better than "someone will be in touch soon", and far better than a promise you cannot keep.
Common setup mistakes
The first is switching on tickets without deciding who reads them. A ticket inbox nobody checks is worse than no tickets at all, because customers now have a number proving they were ignored.
The second is letting the assistant open tickets for questions it should answer. If the same "how do I" question keeps becoming a ticket, the fix is a Q&A pair, not more tickets. The unanswered questions report is a good place to spot these. There is more on that in how SaaS teams deflect tier-1 tickets with a docs-trained bot, which applies well beyond software.
Before you switch it on
Decide who checks the ticket inbox and when. Write your reply-time promise and your priority definitions into the assistant's instructions. Then open a test ticket yourself, with a made-up order number and your own email, and follow it from chat to confirmation email to resolved.
If you want other systems to hear about new issues, sending events with webhooks covers that. For the moments when a person should step in straight away rather than via a ticket, see deciding when a person takes over. Plan details are on the pricing page.