Almost every reseller support question is one of a small set, and most of them are answered by looking at the account rather than by asking the client anything. Knowing which screen answers which question turns a long exchange into a two-minute check.
Open their cPanel instead of asking
From WHM's List Accounts, clicking the cPanel icon beside an account opens it with full access and no password.
This is the single most useful thing in WHM for support, and many resellers never find it. You never need to ask a client for their password, and you should never train them to send one, because a client used to that habit will eventually send one to someone impersonating you.
Check the quota first, always
A full account cannot write. What the client experiences is several unrelated failures at once: email not arriving, uploads failing, forms breaking, the site erroring intermittently.
None of those symptoms mention disk, so the report you receive describes four separate problems. Show Accounts Over Quota answers it in ten seconds and resolves a genuinely large share of tickets outright.
Then find out where the space went before raising the limit. It is usually old backups a plugin has been writing for two years, and deleting those is a permanent fix instead of a postponement.
The questions and where they are answered
"My email stopped." Quota, then the MX records. If they moved mail to an external provider recently, check the mail routing is set to remote: external mail works while the website's own messages vanish otherwise.
"My site is down." Check another of your accounts first. If others are fine it is that account; if several are down it is server-side and a ticket in place of an investigation.
"It was working yesterday." Quota, an expired domain, an expired certificate, or a suspension. Those four cover most of it.
"I cannot log in." Confirm which panel they mean, clients say cPanel for webmail, WordPress admin and everything else. Then reset the password rather than working out what they typed.
"My site is slow." Usually their application instead of the server. Check whether it is slow consistently or only under traffic. The second is a resource ceiling and the first is a code problem.
What is yours and what is theirs
Worth being clear about with yourself, and then with clients.
Yours: the account, its resources, mail delivery, certificates, DNS, and anything about the hosting environment.
Theirs: their application. A broken plugin, a theme conflict, a WordPress error caused by their own change.
You can help with the second and it is worth deciding whether that is included or billable, because if it is undefined, it becomes included by default and you will resent it. Reseller best practices goes into setting that boundary in writing early.
Escalating to your own host
When it is genuinely server-side, what you include decides how fast it is resolved.
The affected accounts and domains. What you observed rather than what the client said. Whether other accounts on the server are affected. When it started. And what you have already checked.
That last one matters: a ticket that says you have confirmed the accounts are under quota and the domains resolve correctly skips an entire round trip.
Keep a record on the account
Whatever you resolve, note it, in your billing system or as a suspension reason where relevant.
Six months later, looking at an account with an unusual limit or an old suspension, the difference between a note and an empty field is the difference between a decision and a guess. Reseller accounts accumulate these, and none of it is memorable.
For the faults that come up repeatedly and what each usually is, Common Issues in Reseller Hosting and How to Fix Them walks through them.
The step that removes most of the friction from this routine is not asking customers for their credentials at all. How to Open a cPanel Account from WHM Without a Password walks through jumping straight in from the account list.
Establish which account before anything else
A ticket that says "my site is down" from an address you do not recognise is the common case, and identifying the account takes seconds if you search by the right thing.
Search by domain rather than by username. Customers know their domain and frequently have never seen the username, which is often a truncation nobody would guess.
Where the reported domain is an addon or a subdomain, it will not appear as a main domain in the list: check whether it belongs to an account rather than concluding it does not exist:
grep -rl 'example.com' /var/cpanel/userdata/*/ 2>/dev/null | head
Getting this wrong sends the first ten minutes of every ticket in the wrong direction. There is more on the screens in the WHM account functions reference.
Reproduce before you investigate
Half of reported problems cannot be reproduced, and that finding is itself the answer.
Load the site yourself, in a private window, from a network other than the one the customer used. Three outcomes and three different responses.
It fails for you too. A real fault; proceed.
It works for you. Local; their network, their DNS, their browser cache, or a block affecting their address specifically. Check whether their address has been blocked before assuming anything else. For releasing it, see cPHulk brute force protection.
It works sometimes. A queue instead of a fault, and the answer is caching rather than investigation.
Say what you did, in the ticket
Access through the panel leaves no trace the customer will see, so the ticket is the only record.
Write what you changed, not only that it is fixed. "Increased the PHP memory limit to 256M and restarted" is thirty seconds of typing that prevents the conversation three weeks later where a setting changed and nobody knows who changed it.
It also protects you: an unexplained change on an account you had access to is a poor position to argue from. There is more on why that access deserves a record in opening cPanel from WHM without a password.
Recognise a pattern instead of a ticket
Several accounts reporting similar symptoms in the same period is a server problem being reported as individual faults.
Before working through them separately, check the machine: load, disk, and whether the services are running. Two customers reporting slowness within an hour is worth one look at the server. See service status and server health.
The same reasoning applies over time: the same ticket arriving repeatedly from different customers is a documentation gap in place of a support load. For converting it, see reducing support tickets with documentation.