How to collect website change requests from non-technical clients

Collecting website change requests from non-technical clients is one of those jobs that looks trivial and quietly eats your week. The client knows something is wrong with their site. You know how to fix things that are wrong with websites. And yet the hand-off between those two facts routinely takes days, three channels, and at least one photo of a monitor taken with a phone.

Where requests actually arrive

If you maintain client sites, requests don't arrive in a queue. They arrive:

• in an email with the subject "website" and no page link
• as a text message while you're at dinner ("the thing is broken again")
• in a screenshot cropped to exclude the URL bar, the error, and most of the page
• verbally, at the end of a call about something else
• forwarded from someone else's email, with the original context stripped

None of these are your client being difficult. Each one is them reporting the problem in the most natural channel available at the moment they noticed it. The chaos isn't a client failure — it's the absence of a system.

Why "just email me the details" doesn't work

The instinct is to reply with questions: What page were you on? What browser? Can you send the exact wording? This fails for a predictable reason — you're asking a non-technical person to do a developer's intake job. They don't know what the address bar is called. They can't tell Chrome from "the internet." They genuinely cannot see the difference between the staging site and the live one.

So the answers come back partial, a day later, and you burn a reply cycle per missing fact. The ten-minute fix now carries an hour of unbillable coordination, and the client's honest takeaway is that small changes take a week. Neither of you is wrong. The process is.

What good capture actually looks like

A workable intake system has four properties, whatever tools you use:

1. One channel. Every request lands in the same place, whatever the client's habits. If they email you anyway, you forward it into the channel — the queue stays the single source of truth.
2. Capture happens on the page. The request is made while looking at the problem, not reconstructed from memory afterwards. That's the difference between "the button is broken" and this button, on this URL.
3. Context is collected automatically. Page URL, browser, device, what the element currently says, what happened before — anything software can record, software should record. Every fact you extract from the client by interrogation is a fact your system failed to capture.
4. The loop closes. The client hears when the fix is live without asking. Otherwise the "is it done yet?" emails become their own workload.

Getting most of the way there for free

You can get surprisingly far without buying anything: publish a single intake address or form, and give clients a change-request template that asks for the facts in their language — what, where, what it says now, what it should say instead. Forward every stray text and email into that queue yourself, and confirm to the client when each item ships.

The residual problem is that templates depend on the client filling them in, and the automatic-context part — browser, console errors, exact element, what they did beforehand — isn't something a form can collect. That's the gap purpose-built capture tools close: the client points at the thing on the live page, says what they want in their own words, and the software records the context and asks the clarifying questions. It's the approach we built SiteUpdate around, and the reason its tickets arrive dev-ready instead of vague.

However you get there, the principle holds: stop asking non-technical people to be technical. Move the burden of a complete request off your client and onto the system — that's the entire game.