Ask about one task the person actually attempted.
“Do you like the system?” can start a conversation, but it rarely identifies what to improve. Someone may like the layout and still struggle to find the current estimate. Another person may dislike a new routine that nevertheless gives them the information they need.
Choose one customer path and speak with people who have used it. Ask them to recall a recent task: finding an inquiry, responding to a scope question or handing work to a colleague. Keep practice examples labeled as practice. Someone who has not used the process cannot report how it behaves in everyday work.
Explain the purpose of the discussion and who will see the notes. Do not promise anonymity unless your actual collection method provides it. Focus on the work, and leave identifying customer details out of a general feedback sheet.
Use questions that leave room for an unexpected answer.
Ask for the sequence before suggesting a cause or solution. “How much faster was it?” assumes an improvement. “What happened when you tried it?” lets the person describe success, friction or uncertainty.
On a small screen, swipe or scroll sideways to read the full table.
| Ask | What you are trying to learn |
|---|---|
| What were you trying to do? | The task and the result the person expected. |
| Walk me through what happened next. | The actual sequence, rather than an overall impression. |
| Where, if anywhere, did you hesitate or need help? | A specific point to investigate without assuming there was a problem. |
| What did you do to continue? | A workaround, a colleague’s help or a task left unresolved. |
| What would you keep, and what would you change? | Useful behavior to preserve as well as suggested improvements. |
Let people finish their account. A remembered example is valuable, but it is still a report until the relevant detail is checked. Do not turn a rough recollection of effort into a measured time saving.
Compare the owner’s view with the person doing the work.
Fictional example: A repair-business owner, Sam, checks a list and sees that every estimate request has an assigned person. Sam reports: “I can see who owns each request now.”
Jamie, who handles the office follow-up, describes a different part of the same path: “I found my request, but there were two estimate attachments with similar labels. I asked the estimator which one answered the customer’s latest change.” Jamie completed the task after getting help; the extra effort was not timed.
Those accounts can both be true. Assignment is visible to the owner, while choosing the current estimate remains difficult for the office. Ask what identifies the approved version today and whether the instructions explain it. Do not conclude that the whole process failed—or that assignment alone made it successful.
If a closer review is needed, use an authorized, redacted example. Replaying a real customer action merely to demonstrate friction could send another message or alter a record.
Separate the kind of evidence from the strength of the opinion.
Keep different findings distinct. A strongly expressed preference is not automatically a defect, and an observed mismatch does not establish its cause.
On a small screen, swipe or scroll sideways to read the full table.
| Finding | Type of finding | Useful next check |
|---|---|---|
| Jamie says choosing an attachment required asking a colleague. | Reported difficulty. | Check the specific request and current-version instructions. |
| An authorized review shows two similar attachment labels with no visible current-version reference. | Observed condition in that reviewed example. | Compare it with the agreed process; do not assume every request has the same issue. |
| Sam would prefer larger attachment text. | Preference to evaluate. | Ask which reading task is difficult and test an appropriate example. |
| Someone proposes automatic pricing in a new customer chat. | New requirement proposal. | Review capability, scope and responsibility separately. |
A difference from agreed behavior may need a specific problem report. A desired new behavior belongs in a change brief, not a silent addition to the work.
Choose one decision that the evidence can support.
In the fictional example, the next decision is to clarify how the current approved estimate is identified. Sam accepts responsibility for checking the existing approval process with the estimator. Jamie will then use a fictional request in a practice setting to see whether the approved version can be identified without a separate clarification.
The agreed review point is after that check and any necessary approved instruction update. Adding a chat channel, changing prices and rebuilding the customer process are outside this action. The result remains “not yet checked” until the review happens.
This decision is useful because it addresses a specific task and preserves working ownership. It does not claim that a revised label will save hours or win more jobs. If the check finds no missing instruction, investigate another explanation instead of implementing the first suggested fix anyway.
Show the team what happened to its feedback.
Download the blank customer-process feedback worksheet (CSV). Use one row per task account. Record the reported difficulty, evidence still needed, proposed change, decision, accepted owner and agreed review point. Keep completed notes in the workspace approved for that information.
Close the loop with a short account of what was checked, what was decided and what remains open. “We heard you” is incomplete if the team cannot tell whether anything changed. Declining or deferring a suggestion can be a useful outcome when its reason is explained.
These questions are a practical discussion aid, not a validated survey or proof of customer results. Staff feedback complements the operating review; it does not replace records or establish revenue impact. Feedback for improvement is also separate from permission to publish someone’s words, name, screenshot or results.