An IT managed service provider receives a support request from a client: "Email isn't working." That is all. The helpdesk replies asking who is affected, whether it is all email or just sending, whether there is an error message and when it started. The client replies an hour later. Another round of questions follows. By the time an engineer starts work, half the morning has gone.
Vague support requests are one of the biggest drains on helpdesk time. Capturing the right details first time fixes much of it.
Step 1: know what a useful ticket contains
A ticket an engineer can act on usually includes who is affected (one person or everyone), which device, application or system, what the problem is in the user's words, any error message or screenshot, when it started and whether anything changed, and how urgent it is and what work it is stopping.
Step 2: ask in plain language
Users are not engineers. "What does the error say?" works better than "please provide diagnostic output". "Is it just you, or your colleagues too?" works better than "scope of impact".
Step 3: separate urgent from routine
A server outage affecting the whole office needs immediate attention. A single user's printer can wait. Asking about impact lets the helpdesk prioritise. How AI can help sort a support inbox is covered in support ticket triage: letting AI sort the inbox.
Step 4: offer self-help where it fits
Many requests are routine: password resets, connecting to Wi-Fi, setting up email on a new phone. Published guides can solve these without a ticket.
Step 5: capture it in conversation
SpideyChat for IT service providers can ask these questions in conversation at any hour, share relevant self-help guides from your own pages and create a ticket with the details for the helpdesk. Turning chat into tickets is covered in support tickets from chat.
User: Email isn't working. Assistant: I'm sorry about that. So an engineer can help quickly, is it just you or others in the office too? Are you unable to send, receive or both? And is there an error message on screen?
Step 6: confirm and update
Once a ticket is created, confirm it with a reference and expected response time. Users who know their issue is logged are less likely to send repeat messages.
Remote support and access
Many issues can be fixed remotely, but engineers need permission and a way to connect. Explaining how remote support works, and asking whether the user is at their desk and able to accept a remote session, speeds up the fix. Users who know what to expect are more relaxed about letting an engineer connect, and less likely to be caught out by a request they were not expecting.
Out-of-hours issues
Some clients work evenings or weekends and need to know what support is available then. Publishing out-of-hours arrangements, and capturing issues that arrive overnight with full details, means the first engineer in the morning can start work straight away rather than chasing information.
Step 7: learn from tickets
Patterns in support requests reveal problems worth fixing, and sometimes clients at risk of leaving. Spotting those signals is covered in churn signals hiding in support conversations. Better first-time capture also reduces costs, as described in reducing support costs without reducing support quality.
Setting it up
Write your core support questions, publish self-help guides for common issues and set the assistant to capture tickets. The guides to installing the widget and training your bot explain how.