A good website support request does not need technical language. It needs a clear description of what you were doing, what you expected to happen and what happened instead.
Start with the page and the task
Include the address of the affected page or website. Then explain the task in ordinary language: submitting an enquiry, updating an event, taking a payment, signing in or sending an email.
If the issue affects one particular customer, order or form entry, include its reference number where appropriate—but avoid unnecessary personal information.
Describe what happened
A short sequence is usually enough:
- What you clicked or entered.
- What you expected the website to do.
- What appeared instead.
Copy the exact error message when there is one. A screenshot is useful when it shows the entire browser window, including the page address. Mention whether the problem happens every time, only on mobile, or only for one user.
Choose urgency carefully
Critical means the website is offline, appears compromised, cannot take essential enquiries or payments, or is causing a serious business interruption. A spelling correction, new photograph or routine content change is important, but it is not usually critical.
Keep the conversation in one ticket
Add new information to the existing ticket rather than opening another one. That preserves the history and prevents two investigations of the same problem.
Never paste passwords, recovery codes, API keys or payment details into a ticket. Grey Lily Media can arrange a safer access method when access is required.
What happens after you submit
Your request is logged with its date, priority and conversation history. Grey Lily Media can then reproduce the issue, check recent changes, inspect logs or ask for one specific piece of missing information.
Support requests are normally reviewed within one business day. Critical issues are assessed first, but choosing Critical for routine work does not make the work faster—it makes the queue less useful for everyone.
A simple support-request checklist
- The affected website or page address.
- The task you were trying to complete.
- The actual result and expected result.
- The exact error message or a useful screenshot.
- How urgent it is and why.
That is enough. You do not need to diagnose the cause before asking for help.
Need help with this?
Clients can open a secure support request and keep the conversation in one place.
Keep reading
Every Website Form Should Have One Job
A practical way to decide what a website form should ask, where its answers should go and how it can reduce work for customers and the business.
Read article
Your Website Isn’t Broken. Your Business Model Is.
Website problems often begin with unresolved decisions about services, pricing, capacity, policies and customer fit. Use your website project to find and fix the right problem.
Read article
Simplicity Is Expensive to Create: Why Clear Websites Take More Work
A simple website is not the absence of information. It is the result of clear decisions about services, prices, pathways and responsibilities. Here is the work that makes simplicity possible.
Read article