A useful support case connects the customer's symptom to a specific service, action and timestamp. Collect that evidence before changing several settings or repeating a write request whose result is uncertain.
IN THIS ARTICLE
01 Record the affected workflow
- Identify the Hosting Suite and WHMCS versions, provider, product and service.
- Record the exact page, action and safe error text. Include whether the problem affects one account, one server or all products.
- Check the service's status, owner, server assignment and hosting username.
- Inspect the relevant module history, WHMCS activity or module log and provider response around the same time.
- Note recent configuration, package, credential, DNS or software changes.
- Reproduce with a harmless read operation or a disposable test resource where possible.
02 Use the right history
Renewal problems belong with their renewal operation, invoice and transaction records. AI credit problems need the service balance, purchase invoice and request usage. Website automation failures need the schedule and task history. Migration cases need their request status and staff replies.
The module records administrative changes and certain sensitive actions such as credential reveal. Use those records to establish who changed a setting and why. A provider timeout does not prove the underlying operation failed, so inspect the remote state before retrying a create or delete action.
What should I remove before sharing diagnostic evidence?
Remove API keys, passwords, private keys, reset links and unnecessary customer data from screenshots or log excerpts. Show identifiers only to the support team that needs them. Do not publish a complete configuration file to explain one missing setting.
Debug logging can capture sensitive request parameters. Enable it only for the controlled diagnostic window, review what it records and disable it afterward. Use your organisation's approved retention and access rules for diagnostic files.
03 Resolve one layer at a time
If all account tools fail, inspect the server connection before product styling. If one tool is missing, inspect product, provider and account capabilities before changing credentials. If a customer is blocked while an administrator succeeds, compare permissions and service eligibility.
For a broken administrator interface caused by a customization, use the custom-code safe mode and restore the last working snippet. For a stale shared-settings save, reload and compare the current revision rather than overwriting another administrator's work.
04 Close the case with verification
Repeat the original task after the correction and inspect its result on the server or invoice. Record the cause, change and successful verification. Keep any unresolved limitation explicit so a temporary workaround is not later mistaken for a permanent product capability.