The message lands on a Tuesday at 9:12am: “the site’s broken.” Three words, and already two rounds of back-and-forth to get through before anyone can even start looking. A properly written support ticket does the opposite: it carries half the diagnosis inside it, and the work begins within the minute. Here are the seven pieces of information that change everything, a template to copy as it stands, and what you are entitled to demand in return.
Why a written ticket beats a phone call
The phone reassures; the written word repairs. A call leaves a trace in somebody’s memory, a ticket leaves a trace in a history. The difference shows three weeks later, when the same symptom comes back and nobody remembers what was done about it the first time.
- Nothing gets lost. The exact error message, the time, the address of the page: all things you cannot dictate over the phone without distorting them.
- Prioritizing becomes possible. Between a store at a standstill and a typo to correct, the order is not up for debate. But the two requests have to be written down side by side for anyone to see it.
- Someone else can pick up the case. Another engineer reads back through the thread and knows where the matter stands, without making you tell the whole story a second time.
- You keep proof of what was asked for and what was delivered, which comes in useful the day a disagreement over scope appears.
One honest caveat: if the store is completely down on a busy Saturday, call first and open the ticket afterwards, where it then serves as the written record. For everything else, our ticket-based technical support deals with a written request faster than with a running commentary on the phone.
The seven pieces of information that save an hour
- The exact address of the page. Not “the contact page”: the full address, copied from the browser bar. A thirty-page site often has three different forms on it; knowing which one is affected saves testing all three.
- What you were doing, step by step. “I clicked Add to cart, then Checkout, and the page stayed blank.” Three sentences are worth more than an adjective.
- What you expected, and what actually happened. This distinction separates a fault from a misunderstanding: a feature that never existed is not broken, it is waiting to be built.
- Since when, and what changed just before. An update, a new post, a change to a DNS zone, a new plan at your host: the most recent change is always the first suspect.
- The browser, the device and the network. A fault that shows only in Safari on iOS, or only from the office wifi, has nothing in common with a fault that shows everywhere: in the second case the cause is on the server, in the first it lies somewhere else.
- A screenshot, or better still, a short video. The full error message, not a summary from memory. The codes matter: 403, 404, 500 and 503 lead down four different paths.
- Whether it can be reproduced. “Every time” and “one time in five” are not handled the same way. Ask a colleague to repeat the steps from another machine: their answer is often worth an hour of searching.
The ticket template to copy
Copy this block, fill in what you know and leave the rest blank: a half-filled template is still ten times more useful than a free-form message.
Subject: the feature affected + the symptom in four words Address affected: the full address of the page Since when: date and time of the first symptom What changed before: update, new content, DNS, hosting, nothing Steps to reproduce: 1. … 2. … 3. … Expected result: what should have happened Actual result: the exact message, copied out or in a screenshot Environment: browser and version, device, network Reproducible: yes / no / intermittently Impact: how many people, which function is blocked Suggested urgency: P1, P2, P3 or P4 Access: available / to be created Attachments: screenshot, video, export of the error log
A completed example, to show what it looks like in real life:
Subject: quote form, no email received Address affected: the “request a quote” page of the site Since when: Thursday, around 2pm, a customer told us on Friday morning What changed before: six plugins updated on Wednesday evening Steps: 1. fill in the four fields 2. click Send 3. the “thank you” message appears Expected result: an email arrives at the contact address Actual result: nothing, neither in the inbox nor in the junk folder Environment: Chrome on Windows, and Safari on iPhone, same symptom Reproducible: yes, three attempts out of three Impact: every incoming sales inquiry Suggested urgency: P2
That ticket gets handled without a single follow-up question. A confirmation message that appears while nothing arrives points to the sending of the email rather than to the form itself, and the previous day’s update names the first lead to pursue.
Urgent, important, or merely annoying
An honest priority scale is defined by impact, never by emotion. Marking everything urgent amounts to prioritizing nothing, and it holds up the real emergencies.
| Level | What it covers | Example |
|---|---|---|
| P1 | Site entirely unavailable or compromised | Error 500 on every page, redirect to an unknown site |
| P2 | A commercial function blocked, the rest working | Payment refused, silent form, customers unable to log in |
| P3 | Visible degradation, nothing blocked | Image distorted on mobile, page taking eight seconds to appear |
| P4 | Enhancement or convenience request | Add a field, change a color, create a page |
A simple rule of thumb for deciding: if the fault is costing money every hour, it is P1 or P2. If it annoys you without costing anything, it is P3. If it improves something that already works, it is P4. Before opening a top-level ticket, run through the checks to make when your site goes down. At Aloha Pixel, an intervention is booked one at a time from the support ticket page: a ticket costs €89 for an hour of work over video call, and the pack of five tickets €399 (VAT not applicable, article 293 B of the French tax code). The first slot is offered within 48 business hours.
Get your logins ready before you need them
Half of all delays in getting a fix come not from the diagnosis but from waiting for a password. Gather these five sets of credentials once and for all, in a password manager, and the question will never come up again: the site’s admin area, the hosting, the domain name registrar, the email service attached to the domain, and the analytics tools. The last two are forgotten every single time, yet a silent form is diagnosed on the email side, and the scale of an incident is read in Search Console.
Four rules are enough to keep all of this safe: a named account for each engineer rather than a shared one, no password ever sent by email or instant message, two-factor authentication switched on for sensitive accounts, and access revoked at the end of the job. You remain the holder of every one of your accounts, without exception. The IT hygiene guide from ANSSI, the French cybersecurity agency (in French) sets out this approach to account management, and the eight essential WordPress security measures complete the picture on the site side.
What you are entitled to expect in return
A well-written ticket deserves something in return. Here is what to insist on, preferably before you sign.
- An acknowledgment of receipt confirming that the request has been logged and the priority level assigned, which may differ from the one you proposed, along with the reason.
- A stated response time, set down in black and white, not “as soon as possible.”
- A progress update as soon as the work runs past the time announced, even if only to say that the search is still on.
- An explanation in plain language. “The cache was corrupted” is not an explanation; “a caching plugin was serving an outdated version of the home page, we cleared it and excluded the checkout page” is one.
- A written report at the end of the intervention: cause, fix, preventive measure.
Beware of a confusion that many contracts do nothing to clear up: the response time is not the resolution time. A two-hour response guarantee commits nobody to anything about getting the site back online. Ask for the two figures separately.
Our position: what belongs in support, and what does not
Drawing a clear boundary reassures more than it holds anyone back. Under ongoing technical support: fixes, supervised updates, restores, availability incidents and small content changes. Under a project: a new feature, the redesign of a page, an integration with business management software, the creation of a customer area.
That line protects both sides. It spares the client from watching their support turn into a permanent queue, and it spares the provider from delivering for free, in dribs and drabs, a piece of development that deserved proper scoping. When a request tips over to the project side, it is quoted separately and scheduled: slower to announce, much faster to deliver. Our website plans that include technical support rest on this distinction, and requests that amount to a project follow a different path.
Frequently asked questions
What if I cannot reproduce the problem?
Report it as it is, with the exact time it happened and what you were doing. Server logs keep errors with a timestamp: a precise time is often enough to find the trace of an incident that no longer recurs.
Do I have to hand over my admin login?
Yes, but never your own. Create a dedicated account in the engineer’s name, with two-factor authentication, and delete it at the end of the job. That way you keep a record of who did what, and you take back control in a single step.
How long before I get a response?
That depends on the priority level stated, and the time frame should be written into your contract. Insist on two separate figures: the response time and the target resolution time for each level.
Can I put several requests in a single ticket?
No. One subject per ticket. Three requests in the same message make the thread unreadable, rule out any prioritizing and guarantee that at least one of the three will be forgotten.
What to take away
A good ticket is not a piece of paperwork, it is half the diagnosis already done. The seven pieces of information take five minutes to write and save an hour of intervention. Keep the template in your notes and use it from the very next request: the difference will show in the first exchange.
Also worth reading: what happens when maintenance is ignored
