What to put in a first support email so it gets fixed in one reply
Most support threads take three rounds because the first email is missing one small thing. Here is what the desk needs from you, what it can find on its own, and a short template you can paste into any email app.
A support request usually takes longer than it should for a boring reason. The first email says what is wrong but not where, or where but not when, and the reply that comes back is a question rather than a fix. That round trip costs you a day. It is nearly always avoidable, and the fix is about five extra words.
This is what the desk is actually reading for when your message arrives, in the order it reads for it.
The one sentence that does most of the work
Before anything else, write a single sentence in this shape:
I was trying to do X, on page or account Y, and instead Z happened.
That sentence alone resolves a surprising number of requests, because it separates the three things that usually get blurred together: your intention, the surface it happened on, and the actual behaviour. “The form is broken” is none of those. “I submitted the contact form on our /pricing page and got a spinning button that never finished” is all three, and somebody can start reproducing it in the time it takes to read it.
If you write nothing else, write that sentence.
Five things worth including
The exact address. Not “the booking page” but the full link you had open, copied out of the address bar. Sites often have three pages that could be described the same way, and picking the wrong one wastes the first twenty minutes. The same goes for a GoHighLevel sub-account: the name as it appears in the account switcher, not the client’s trading name, which may be different.
Roughly when it last worked. “It was fine on Thursday” is one of the most useful things you can say, because it turns an open investigation into a search through a specific window. Almost everything that breaks broke because something changed, and a date narrows the list of candidate changes from hundreds to a handful.
Who it affects. You only, everyone on your team, or your customers. That single detail decides how the request is prioritised, and it is the one people leave out most often. If customers cannot buy or cannot book, say so in the first line and put the word DOWN at the front of the subject. Nobody is annoyed by an escalation that turns out to be smaller than feared.
The error, copied as text. A screenshot of an error is good. The error copied as text is better, because it can be searched against logs and against the code. If there is a reference or request ID in it, that string is often the fastest route to the cause.
What you already tried. Cleared the cache, tried another browser, asked a colleague to check on their phone. This is not to prove you did your homework. It is so nobody spends an hour suggesting the thing you did before you wrote in.
What almost never helps
Forwarding a long internal thread with no note at the top. Somebody has to read fourteen messages to work out which two lines are the request, and the risk of reading it the wrong way round is real. Add two lines at the top saying what you need, then leave the thread below as context.
Sending the same problem to two addresses at once. It does not make it faster. It makes two people start the same investigation, and the reply you get may be the one written by whoever had less information.
Describing the fix rather than the fault. “Can you put the SPF record back” might be right, and it might be that SPF was never the problem. Tell the desk what you are seeing and what you think the cause is, clearly labelled as a hunch, and you get the benefit of both.
Send it anyway if you are not sure
None of this is a form you have to complete correctly before anyone will help you. If you do not know the page address, or you cannot tell whether it is a website problem or a GoHighLevel problem, say that and send it. Working out which surface a problem belongs to is part of the job, and it is a fast part. A vague email today beats a perfect email on Friday.
The only thing to genuinely avoid is putting a password in the message. If access is needed, the reply will suggest a safe way to hand it over. Passwords sent by plain email sit in two inboxes and several backups forever, and nobody can un-send them.
A template you can paste
Subject: [DOWN / BROKEN / QUESTION] short description
What I was doing:
Where (full link or sub-account name):
What happened instead:
Last known good:
Who it affects (me / my team / customers):
Already tried:
Attached: screenshot or short recordingDelete any line you cannot answer. A half-filled version of this is still better than a paragraph, because the shape of it makes the gaps obvious to both of us.
What happens after you hit send
Your email becomes a numbered request as it arrives, so it is not sitting in one person’s inbox waiting for them to get back from lunch. A person reads it and replies to confirm what they understood and what happens next, within one business day and usually a lot sooner in working hours. If the first reply asks you a question, that is the one round trip this article is trying to save you.
Keep replying on the same thread. Every message on it stays attached to the same request, which means the person picking it up on day three can see the whole history without asking you to repeat yourself. Starting a fresh email for the same problem splits it into two requests, and that is the one genuinely inconvenient thing you can do to your own ticket.
When it is fixed, you get told what was wrong in language you can repeat to somebody else, and if it is something you can avoid next time, that is in the note too.