Support tickets are resolved at the speed of the information in them. A ticket saying "my site is down" starts a diagnosis from nothing; the same problem described properly is often answered in one reply.
None of this is about being polite. It is about which round trip you skip.
Include these five things
The exact error text. Copy it, or attach a screenshot. "It says there is an error" and a 500 with a specific message are entirely different tickets.
The exact URL where it happens, including whether it is one page or all of them.
When it started, as precisely as you can, with your timezone. Logs are searched by time, and "recently" cannot be searched.
What changed shortly before. An update, a plugin, a DNS change, an edit to a file. This single line resolves a large share of tickets on its own.
What you already tried, so nobody repeats it and so they know what has been ruled out.
Say what you expected and what happened
Two sentences, and they prevent the most common misunderstanding.
"I expected the contact form to email me; no email arrives and the page says thank you" is a specific claim. "The contact form is broken" could mean six things, and the first reply will ask which.
Describing the behaviour rather than your diagnosis matters too. "The database is down" is a conclusion; "pages load but the shop shows a connection error" is an observation, and the observation is more useful even when the conclusion turns out to be right.
Say whether it affects everyone
Check from a different network before writing: a phone on mobile data is ideal.
If it works there, the problem is your access rather than the site: browser cache, a stale DNS entry, or your address blocked by a security tool after failed logins. That last one is common, self-inflicted, and fixed from the control panel rather than by support. There is more on the triage in What to Do When Your Website Goes Down.
Including that result either narrows the problem or resolves it before you send.
One problem per ticket
Three unrelated issues in one message means the reply addresses one and the others are lost, or the whole ticket waits for the slowest.
Separate tickets are tracked separately, closed separately, and escalated separately. It feels like more work and it is faster.
Write a subject that says the problem
"Urgent" is not a subject. Neither is "Website issue".
"500 error on all pages since 14:00 today" tells whoever triages exactly what it is and how urgent it genuinely is, and it means the right person picks it up first.
Look at the error log first
For anything on your own site, the log usually names the file and the line. Pasting that into the ticket turns a diagnosis into a fix.
It also tells you whether the problem is yours at all: an error inside a plugin is your side, and a server-level failure is theirs. Understanding cPanel error logs deals with finding it.
Know what support covers
Most hosts draw a line between the server and what runs on it: a broken server is theirs, a broken plugin is yours.
That is not obstruction. It is the difference between hosting and development, and asking within it gets faster answers. Asking outside it gets a polite redirection and a lost day.
When you are unsure, say what you are asking for explicitly: "is this a server-side limit or something in my application" is a fair question and often answered in one line.
Do not send credentials by default
If access is genuinely needed, most hosts already have it for your account, or will ask.
Never put a password in a ticket that is emailed back and forth. Use the provider's secure field if one exists, and change the password afterwards if you did share one.
For a third party. A developer working on your site, create a separate account for them rather than sharing yours. There is more on the alternatives in securing your hosting account.
Give it time before chasing
Replying "any update?" every twenty minutes moves the ticket to the back of the queue on some systems, because each reply resets its position.
If it is genuinely urgent, say why in the original message; a shop that cannot take orders is a different priority from a formatting problem, and stating it once is more effective than repeating it.
Close the loop
When it is resolved, say so, and say what fixed it if you found out.
That helps the next person with the same problem, and it means a recurring issue is visible as recurring rather than as three unrelated tickets.
Then write it down yourself. The same problem returning in eight months is much shorter when you have a note saying what it was, which is the same reason to keep a record of what changed and when. Planning maintenance windows explains keeping that log.
From the other side of the desk, most tickets are the same handful of questions. There is more on answering them once in How to Reduce Support Tickets with Documentation.
Gather the evidence before writing anything
The time spent collecting three things before opening a ticket is repaid several times over in the exchange that follows.
date -u
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/
tail -20 ~/logs/example.com.error.log
curl -s ifconfig.me; echo
The exact time in a stated timezone, the response the site gives, and the last lines of the error log. Attach them rather than describing them.
Your own address matters more than people expect, since a problem that affects one network and not others is diagnosed completely differently. Including it turns a question back to you into an answer.
Say what you have already ruled out
A ticket that describes only the symptom invites the recipient to start from the beginning, including the steps you already took.
State plainly what you checked and what the result was: whether it happens in another browser, on another network, for every visitor or one, and whether anything changed recently.
That last question is the one that resolves most tickets. A change made yesterday by somebody who is not you, mentioned in the first message, saves an afternoon of investigation on both sides. If nothing changed, saying so explicitly is equally useful, because it rules out the first thing anybody would ask.