Field and customer operations

Customer requests: track the work until it is actually resolved

Run every customer request through the same nine stages, so nothing is marked done until the customer's problem is gone and you can show it.

For: Service businesses, property and tenant operations, and office teams that receive requests by phone, email, text and web form.

Format: Guide + request tracker (CSV) + message templates
Published: September 9, 2026
Last checked: September 9, 2026
Written by: Dryvn AI editorial
Edited by: Dryvn AI editorial
Reviewed by: Not yet reviewed by a named person
Read as: Editorial (Dryvn's practical method)

The short answer

A request is resolved when the customer's problem is gone and you have evidence of it. A sent message, a booked appointment or a closed ticket is not that.
Every request moves through nine stages: intake, acknowledgement, owner, next update, investigation, authorization, action, outcome verification, closure. Skipping the middle ones is how requests stall.
Two dates keep a request alive: the next action date (what we do) and the update due date (what we tell the customer). When either passes with nothing happening, the request is at risk.
A request waiting on someone else stays open, records the dependency and who is chasing it, and still gets its customer update on time.
Use the tracker fields on this page in your own tool, or download the CSV. Three short status-update templates are included.

The gap between answered and resolved

A customer emails on Monday: the heating in their unit stopped. Someone replies within the hour: "Thanks, we'll get a technician out." That reply feels like good service, and it is. But now the request has left the inbox and entered the part of the business where things get lost. Was the technician booked? Did they go? Did the heat come back on? Did anyone tell the customer? By Thursday the customer emails again, less politely, and the first thing the office does is search for Monday's thread.

This is not a people problem. Everyone did their part. The problem is that the business measured "replied" and never measured "resolved", so nothing told anyone the request was still open. BDC's guidance on efficiency starts with defining the process in the tools you already have before adding new ones [S10]. That is exactly the fix here. A nine-stage process and a tracker with the right fields, in your existing spreadsheet or ticket tool, will catch this request on Tuesday instead of Thursday.

Message sent versus issue resolved
What the business recorded	What the customer experienced	What was missing
Replied within the hour	Reassured on Monday, frustrated on Thursday	Owner and next action date
Technician booked	Nobody showed up; the booking had no confirmation	Dependency tracked, customer confirmation
Ticket closed after the visit	Heat worked for a day, then stopped again	Outcome verification, reopened flag
Invoice sent	Paid for a repair that did not hold	Resolution evidence before closure

The nine stages

A customer request from intake to verified closure

Text version of this diagram

1. Intake (Logged with an ID) → next step
2. Acknowledgement (Customer told, date given) → next step
3. Owner (One name) → next step
4. Next update (Date the customer hears next) → next step
5. Investigation (What is actually wrong) → next step
6. Authorization (Who may approve cost or action) → next step
7. Action (The work is done) → next step
8. Outcome verification (Problem gone, evidence kept) → next step
9. Closure (Customer confirmed where relevant)

01IntakeEvery request gets an ID, a received date and a request type the moment it arrives, whatever channel it came through. A request that only exists in someone's phone is not logged.
02AcknowledgementTell the customer you have it, who owns it and when they will hear next. Do not promise a fix date you have not confirmed.
03OwnerOne named person, not a team. They may not do the work, but they make sure it moves and they answer the customer.
04Next updateSet an update-due date. This is the date the customer hears from you even if nothing has changed. It is the field that stops chasing.
05InvestigationFind out what is actually wrong. Sometimes a call, sometimes a visit. Record what was found, separately from what was reported.
06AuthorizationIf the fix costs money or commits the business, record who approved it and when. If nobody can approve yet, the request is waiting on authorization, and the row says so.
07ActionThe work is done. Record when, by whom, and what was done. This is a claim, not a result.
08Outcome verificationConfirm the problem is gone. A photo, a test, a customer's word. Record the evidence. If it fails, the request is reopened, not closed.
09ClosureClose only after verification, with a closed date. Where it matters, ask the customer to confirm and record their answer.

The tracker fields

Request tracker fields and why each one earns its place
Field	What goes in it	Failure it prevents
ID	Unique, never reused, e.g. CR-0217.	Two threads about the same request.
Received date	When it arrived, whatever the channel.	Not knowing how long a customer has waited.
Request type	A short list you define: repair, billing, booking change, complaint, information.	Everything in one pile.
Owner	One named person.	Requests that belong to the inbox.
Status	Open, waiting on customer, waiting on third party, waiting on authorization, in progress, verifying, closed, reopened.	"In progress" meaning nothing.
Next action / date	The one thing that happens next, and when.	Open rows with no movement.
Update due	The date the customer hears from you next.	Customers having to chase.
Dependency	Who or what the request is waiting on, and who is chasing them.	Blaming a stalled request on the wrong party.
Resolution evidence	What proves the problem is gone.	Closing on a completion claim.
Customer confirmation	Yes, no, not needed, with date.	Closing something the customer still thinks is open.
Reopened flag	Set when a closed request comes back.	Counting a repeat problem as a new one.

Two requests that went wrong, and what the tracker should have said

Illustrative example · fictional

The missed appointment

A fictional appliance-repair business books a Tuesday afternoon visit for a customer whose dryer has stopped heating. The technician arrives; nobody is home. He leaves a card. The office does not hear from the technician until Wednesday, and does not hear from the customer at all. On Friday the customer calls, angry, saying she waited in on Tuesday morning because "that's what the text said".

In the tracker, this request should have moved to "waiting on customer" on Tuesday afternoon with the dependency "customer to confirm new slot; office to call Wed 09:00" and an update due of Wednesday. The acknowledgement message should have carried the confirmed slot in writing, with a request to reply to confirm. The customer confirmation field would have been empty, which is itself the warning. Instead, the row said "booked", which everyone read as done.

Illustrative example · fictional

The unresolved service

A fictional property-management office gets a tenant request: the bathroom fan is noisy. A handyman visits, tightens the housing, and the ticket is closed the same day. Two weeks later the tenant emails again. The fan is noisy. A different handyman visits, replaces the fan, closes the ticket. A month later, the same email, because the real problem is a duct rattling in the ceiling above.

Three requests, three closures, one unresolved problem. The tracker fix is the reopened flag and outcome verification. The second request should have been logged as a reopening of the first, which would have prompted a different question: why did the last fix not hold? Verification for a noise complaint is a call to the tenant a few days later, not a closure on the day of the visit. The evidence field for the third visit would read "tenant confirmed quiet after 5 days, 14 Sep", or it would stay open.

When a request is waiting on someone else

Most stalled requests are not stalled because nobody is working on them. They are waiting: on a part, on a landlord's approval, on the customer to confirm a time, on a trade to call back. The mistake is to let "waiting" mean "parked". A waiting request still has an owner, still has a next action, and still owes the customer an update.

Name the dependency. Not "waiting on supplier" but "waiting on part 4471 from supplier X, ordered 3 Sep, ETA 10 Sep, office to chase 9 Sep".
Keep the update due date. The customer hears from you on the date you said, even if the message is "still waiting on the part, next update Friday". Silence is what makes people chase.
Set an escalation point. Decide, per request type, how long a request can sit in a waiting state before the owner raises it with whoever can unblock it. That number is yours to set from your own experience; there is no universal response-time standard, and this page does not promise one.
Escalate the dependency, not the customer. When the escalation point passes, the owner's next action is to chase the third party or get the authorization, and to tell the customer honestly what is holding things up.

Three status-update templates

Short, honest and specific. Change the details to fit your business. These are original templates written for this guide; they do not claim to satisfy any messaging regulation, and if you send them by text or email you should check consent and opt-out requirements with your own adviser.

Message template · Acknowledgement

Hi [name], we've logged your request about [issue] as [ID]. [Owner name] is looking after it. You'll hear from us by [day], even if it's just to say where things stand. If anything changes at your end, reply to this message.

Message template · Waiting on something

Hi [name], an update on [ID]. We're waiting on [what: the part / approval / a return call from X], expected [date]. Nothing needed from you right now. Your next update from us will be by [day]. Thanks for your patience.

Message template · Closing, with confirmation

Hi [name], [what was done] was completed on [date] for [ID]. Could you let us know by [day] whether everything's working as it should? If we don't hear back we'll follow up once more, and if the problem comes back at any point, reply here and we'll reopen it.

The tracker

Two files: a blank tracker with the eleven columns, and the same columns filled with three fictional rows including a waiting state and a reopened item. Add the columns to your existing spreadsheet or ticket tool if you have one; the value is in the fields, not the file. For requests that are estimates rather than problems, the estimate follow-up workflow uses the same stop-and-update discipline. If you are not sure which handoff to fix first, run the work handoff assessment on your request process.

Downloads · no email required

Customer request tracker (blank)
The eleven columns from this page with three empty rows, ready to paste into your own spreadsheet.
Download .csv
Customer request tracker (fictional sample)
The same columns with three fictional rows: one in progress, one waiting on a third party, and one reopened.
Download .csv

Questions people ask

How do I track a customer request until it is resolved?: Log it with an ID and an owner, give it a next action date and an update-due date, move it through investigation, authorization and action, and close it only after you have evidence the problem is gone. Review the waiting states every week.
What should happen when a service request is waiting on someone else?: It stays open with the dependency named, a date to chase it, and an update-due date for the customer. When it has waited longer than your own escalation point, the owner chases the dependency and tells the customer what is holding things up.
How often should I update a customer on an open request?: On the date you told them, every time, even when nothing has changed. The right interval depends on the request type and your business; set it yourself and record it as the update-due date rather than relying on a general rule.
Do I need a ticketing system to do this?: No. A spreadsheet with these eleven columns and a weekly review does the job for most small businesses. Move to a tool when the volume makes the spreadsheet painful, not before.

Where is work getting stuck between your tools?Find the handoffs in your business that still depend on copying information, remembering follow-ups or chasing people, and get one next action for each gap.
Estimate follow-up: the complete process, with message templatesRun estimate follow-up as a process with an owner, a schedule, stop conditions and a tracker, using five original messages you can copy and adapt.
What should AI be allowed to do without asking?Decide, action by action, what an AI assistant or automation may do on its own, what it may do inside an approved scope, and what always waits for a person.
What is an AI system, a workflow and a loop?Learn the difference between a system, a workflow, an automation, an agent and a feedback loop using two everyday business examples, and map one of your own on a worksheet.

Sources

Dates are when each source was last checked by the editor. Sources support specific claims; they are not endorsements.

S10How to complete a digital transformation in the age of AI · BDC · checked September 9, 2026Supports the point that a defined process in the software you already have is a valid starting point. Not used for any response-time standard or performance figure.

R08 · Published September 9, 2026 · Next scheduled review December 9, 2026 · Teaches process management; not legal, warranty, safety or engineering advice. Examples are fictional unless stated. Part of the Dryvn resource library (17 resources).