Asking Clients for Feedback After Every Delivery
You finish the build. You write the handover doc, record the five-minute walkthrough, push to production, and send the final invoice. The client replies: "Great, thanks — this looks awesome." The invoice gets paid inside a week. Everybody is happy.
And you have learned precisely nothing you can use on the next project.
That reply is not feedback. It is politeness — a socially correct noise that closes the loop and tells you nothing about whether the handover doc was readable, whether the two weeks on the admin panel mattered, whether they wished you had pushed back harder on scope in week one. Six months later you are quoting a similar project and still do not know which parts of your process the last client valued and which they tolerated. You are guessing with confidence, and the confidence came from a compliment.
The fix is not asking more. It is asking better: one specific question, at the moment the answer is still fresh, small enough that answering costs less than ignoring. This post is about how to construct that ask, the two mechanically different ways to deliver it, and how to tell — from data rather than vibes — whether it worked.
The ask has to be specific, timed, and small
Three properties, and dropping any one of them collapses the response rate.
- Specific. "How did we do?" invites "great, thanks" because that is the only answer that fits the question's size. "Was the handover doc enough for your team to pick up, or did they end up asking you things it should have covered?" invites an actual sentence — it names a thing that either happened or did not. The general question gets the general answer, every time.
- Timed to the memory, not the milestone. The best moment is when the work is fresh but the outcome is known — a few days after handover, once they have tried to use what you built without you in the room. Ask at delivery and you get a reaction to the demo; ask three weeks later and you get a reconstruction.
- Small. One question. Not a form, not a five-point matrix, not a "quick survey (only 4 minutes)". A client who owes you a favour will spend ninety seconds on you, and you should spend that budget on the one thing you genuinely do not know.
The corollary stings: you have to decide, before you ask, what you are trying to learn. If you cannot name the decision the answer will change — fixed-price or hourly, whether the weekly demo call earns its hour, whether to write handover docs at all — then you are collecting compliments, and there are cheaper ways to feel good.
There is a whole separate discipline around timing and frequency across channels, and a previous post covers it: how to gather customer feedback without annoying anyone. Everything below assumes you have already decided when — and is about the mechanics of the ask itself.
Two ways to send it, and they are not interchangeable
Mechanically there are two shapes, and the choice matters more than it looks.
The platform sends it. You create a feedback request and the tool emails your client a branded message with your question and a one-click respond link — no login, no form, no account. Right when the ask stands alone: a project wrapped cleanly, nothing else needs saying. In Helmdesk that is request_feedback, and be clear-eyed about it — that call emails a real human the moment it runs.
You send it. You create the same request but ask for a link only — nothing goes out — and drop that link into an email you write yourself. Better whenever the ask belongs inside something else: a personal note, the final invoice, a thank-you with a referral request attached. A branded survey arriving separately from your warm sign-off reads like two different companies contacted them.
const request = await helmdesk.feedback.requests.create({
title: 'One question about the Nightjar handover',
message: 'Did the handover doc cover what your team needed?',
customerEmail: 'dana@example.com',
customerName: 'Dana',
channel: 'link',
internalNote: 'Sent with final invoice #2291 — phase 2 quote pending',
})
// Put request.respondUrl in your own email
await sendFinalInvoice({ to: 'dana@example.com', feedbackLink: request.respondUrl })
Two things to notice. The link channel means nothing is sent on your behalf — you get a respond URL and full control of the wrapper. And the internal note is staff-only context the client never sees, which is how you remember three weeks later that this ask rode along with an invoice — exactly the detail that explains a response you would otherwise misread.
The rule of thumb: if a human at your shop was going to email the client anyway, embed the link. If nobody was, let the platform send it.
The funnel is the part almost nobody looks at
Here is where most feedback processes quietly fail. You send the ask, nothing comes back, and you conclude clients don't do feedback. That conclusion is unearned, because you skipped the step that would tell you which part broke.
A feedback request moves through a funnel: created → sent → opened (they clicked the link) → responded (they answered). Four states, and each gap between them means something different.
- Created but never sent. For a link-only request this means you have not embedded it yet — easy to lose track of when the invoice went out Friday and the link is sitting in a tab.
- Sent, never opened. Your ask did not survive the inbox — a subject-line and sender problem, not a client problem. It is also the strongest argument for the link-only route: an ask inside an email they were opening anyway skips this failure mode entirely.
- Opened, never responded. They clicked, looked, left. The most informative gap in the funnel and the most uncomfortable, because it means the question itself was the obstacle — too broad, too effortful, or too obviously the opening move of a longer survey.
- Responded. The answer becomes a conversation you can reply to — which you should, because a client who wrote you three honest sentences and heard nothing back will not write them twice.
Pulling this up periodically — list_feedback_requests filtered to sent and opened — is a ten-second check that turns "nobody answers these" into "eleven opened it and two answered", which is a completely different problem with a completely different fix.
When the response rate is low, the ask was wrong
The concession, and it is the important one: a low response rate almost never means clients do not care. Clients who just paid an invoice care quite a lot. It means the ask was too broad to answer quickly.
"How was working with us?" requires the client to decide what you are asking, form an overall judgement, and then compose something diplomatic enough to send to someone they may hire again. That is fifteen minutes of work disguised as a one-line question, and they will do it later, which means never. "Was two weeks on the admin panel the right call?" takes eleven seconds because they already have the opinion — you are just collecting it.
So when the funnel shows opens without answers, do not add a reminder. Shrink the question. Then shrink it again. The floor is one thing that either happened or did not, phrased so that "no" is easy to say — and if you cannot bring yourself to write a question where "no" is easy, that reluctance is itself the finding.
The bottom line
"Great, thanks" is what you get when the question was too polite to answer honestly. Ask one small, specific, uncomfortable thing while the work is still fresh, put it wherever your client was already going to be reading, and check whether it opened before you decide what it means. The client who said your project looked awesome was not lying — they just were not answering, because you had not asked.
One question, sent your way or theirs
Feedback requests that email the client, or link-only requests you embed in your own note — with the open and respond funnel tracked either way.