Support Tickets That Get Answered

Why the first message decides it

Support works through a queue, and each exchange costs a cycle: you write, they read hours later, they ask a question, you answer hours later.

A ticket resolved on the first reading takes hours. The same problem taking four exchanges takes days, without anybody being slow.

So the useful skill is not persistence. It is anticipating the questions and answering them before they are asked.

There are about six of those and they are the same every time.

The six things to include

• The exact address where it happens.
• The exact error, copied or screenshotted.
• When it started, as precisely as you can.
• What changed around then.
• What you have already tried.
• How to reproduce it, step by step.

Together those fit in a short message and remove almost every reason for a first reply that is a question rather than an answer.

Describe the symptom, not your theory

The most common way a ticket goes wrong, and it is usually well-intentioned.

Somebody writes that the database is corrupted, or the server is out of memory, having read something similar online.

Support then investigates that theory, finds it is not the case, and replies asking what actually happened, which has cost a day.

Write what you observe instead: this page returns this message, since Tuesday, on every browser I have tried.

Include your theory at the end if you have one, clearly marked as a guess, which is genuinely useful and should not be the headline.

Be precise about when

The single most useful piece of information and the one most often given vaguely.

Recently, or the last few days, is not something anybody can search logs against.

Tuesday afternoon, or since about four o'clock yesterday, lets somebody look at exactly that window and frequently identifies the cause immediately.

Pair it with what happened around then: an update, a plugin installed, a migration, a change somebody made, or nothing that you know of.

Nothing that I know of is a legitimate and useful answer, and it is better than omitting the question.

A worked example

A business reported that their website was not working, in a message of one line.

The first reply asked which page and what error, arriving four hours later. The second asked when it started, arriving the following morning. The third asked whether anything had been changed.

The problem was resolved on the third day.

The following time they wrote: the address, a screenshot of the error, that it began after a plugin update at about ten the previous morning, that it affected every page except the homepage, and that they had already cleared the cache.

It was resolved in one reply, within the hour, by somebody who could see immediately what had happened.

The problem had been of comparable difficulty both times.

Say what you have already tried

Worth its own line, because it prevents the most frustrating exchange available.

Without it, the first reply will suggest clearing your cache, trying another browser, and restarting your machine, which you did before writing.

Listing those turns a wasted cycle into a starting point, and it signals that the person writing has already done the obvious things.

Include the results: cleared the cache, no change. Tried another browser and another device, same error.

That also rules out the possibility that it is only happening to you, which is genuinely one of the first things worth establishing.

One problem per ticket

A structural point that speeds things up considerably.

Three unrelated issues in one message will be handled by whoever picks it up, who is specialised in one of them, and the other two will be answered briefly or lost.

Separate tickets get routed separately and progress in parallel.

The exception is where you suspect the issues are related, which is worth saying explicitly, since that connection is itself useful information.

Keep the subject line specific for the same reason: forbidden error on one folder since migration is a better subject than website problem.

Escalating without being difficult

How to push when a ticket stalls, which happens legitimately.

Reply on the existing ticket rather than opening a new one, since a new ticket loses the history and rejoins the queue at the back.

Summarise the state briefly: what the problem is, what has been tried, how long it has been open, and what the business impact is.

The impact is the part that changes prioritisation and the part small businesses omit: our checkout has been failing for two days is different from a page looks wrong.

Ask specifically what the next step is and when, rather than asking for an update, which invites a reply saying it is being looked into.

Stay civil throughout, since the person reading did not cause it and can choose how hard to work on it.

Know what they will not do

Expectation-setting that avoids a category of frustrating exchange.

Most hosts support the server and not what runs on it, so a plugin conflict, a theme error, or a script somebody wrote is outside what they will fix.

They will usually confirm that the server is behaving correctly, which is genuinely useful, and then hand it back.

That is not unhelpfulness, it is the boundary of what was bought, and knowing where it sits saves arguing about it.

For anything on your side of the line, the ticket to write is to whoever maintains the site, using the same six items.

The counter-case

There is a limit to how much preparation a ticket deserves.

Spending twenty minutes documenting a five-minute question is not efficient, and for something simple a one-line message is entirely appropriate.

Some hosts also have genuinely poor support, where no amount of good writing produces a competent answer, and the problem is the provider rather than the ticket.

Where three well-written tickets have all gone badly, that is information about the host rather than a prompt to write a fourth more carefully.

Match the effort to the problem, and keep a record of how the well-written ones were handled.

The template

1. Subject: the specific symptom, not website problem.
2. The exact address and the exact error.
3. When it started, to the hour if possible.
4. What changed around then, or nothing known.
5. What you tried, and the result.
6. Steps to reproduce it.
7. Business impact, if it is material.

Step three does more than the others combined, since a precise time lets somebody search the logs rather than ask you a question.

Being able to observe your own hosting is covered in reading your hosting control panel.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.