Start with the mismatch, not a diagnosis.
A request appears under the wrong teammate. The customer is waiting, and the person reviewing the problem needs more than a screenshot with “please fix.” They need the specific mismatch and enough context to investigate it safely.
Describe what you observed before naming a cause. “The request shows Casey as its owner” is an observation. “The assignment process failed” is a possible explanation. The second statement needs evidence the first does not provide.
Compare the result with the agreed process or a current instruction. If the expected behavior was never agreed, say so. A proposed improvement may need a change request rather than a repair. This guide helps prepare the evidence; it does not decide service coverage or promise a resolution time.
Turn a vague complaint into an investigable report.
Fictional example: A repair business expects Morgan, its office coordinator, to own incoming estimate reviews. At 09:20 on September 16, 2026, Morgan sees Casey listed on request E-042. All times below are Chicago time, CDT (UTC−05:00).
Vague report: “Assignments are broken. Nobody is getting leads.” That statement does not identify the affected request, establish the extent of the problem or explain the expected result.
On a small screen, swipe or scroll sideways to read the full table.
| Report detail | Evidence to give the reviewer |
|---|---|
| Affected step | Ownership of an incoming repair-estimate review, request E-042. |
| Expected | Morgan owns this kind of estimate review under the team's current written process. |
| Observed | At 09:20, the request's owner field displayed Casey. The request was still awaiting review. |
| Last confirmed result | Morgan's 09:05 check recorded Morgan as owner of E-042. The reason for the later difference is unknown. |
| Checks completed | Morgan confirmed the business workspace and request reference, then read the request details using the office role. No duplicate request was created. |
| Known impact | Ownership needs clarification for this request. Other requests and any effect on customer response time have not been checked. |
This report makes a narrow claim the reviewer can investigate. It does not infer that every new inquiry is affected, that a message failed or that Casey caused the change.
Check the view without repeating the customer action.
Before escalating, confirm the workspace, known request reference, spelling and active filters. Note which role you are using. A filtered list and a request's detail view can answer different questions, so describe where the result appeared.
Read existing activity if your role permits it. Record what you checked and what you could not see. Do not use another person's login, change permissions or create a second customer record just to make the expected screen appear.
A reproduction is not always harmless. Resubmitting a form, making a test booking or repeating a customer action may create real work or send messages. Give the reviewer the original evidence first. If another test is necessary, agree on its exact scope, fictional data and possible effects before anyone runs it.
Keep the customer work owned while the issue is reviewed.
The person investigating the discrepancy and the person responsible for the customer's next step may be different. Name both. An investigation ticket does not automatically transfer the customer commitment to whoever receives it.
In the fictional example, Morgan accepts temporary coordination of E-042 at 09:28. Casey is told through the team's approved internal route so neither person assumes the other is contacting the customer. They check the existing conversation before any further action. This agreement is recorded without pretending the displayed ownership has already been corrected.
Record any real commitment at risk and the next agreed check. If the extent of the problem is unknown, keep it unknown. For a wider workspace interruption, use the separate temporary-work and reconciliation plan; the problem report is not a substitute for continuity instructions.
Send only the evidence the recipient needs.
Download the blank problem-report worksheet (CSV). Keep the completed report in the approved workspace and send it through the support or operations route your business actually uses.
Use a request reference instead of copying the full conversation. If a screenshot helps, crop it to the relevant field and necessary context. Redact unrelated customer details, private messages, account information and other records. Never include passwords or security codes. Keep the original evidence in its permitted location and note what was redacted.
Name the intended recipient and distinguish “sent” from “received” or “assigned for review.” Ask for the next step through the agreed process. Do not invent support hours, a deadline or an acknowledgment merely because the report is complete.
Close the loop with a specific retest.
A changed setting or reassuring reply is not the same as checking the affected step. The person responsible for the correction should define what will be reviewed, who can perform the check and what result would meet the agreed behavior.
For E-042, the immediate check is whether the correct request now shows the intended owner and whether that person can see the remaining action. That alone would not prove that all future inquiries will be assigned correctly. Any broader test needs its own authorized scope and result.
Record the observed retest result, reviewer, time and remaining uncertainty. Use the customer-path review checklist where a wider review is needed. Keep “resolved,” “partially checked” and “still under investigation” distinct so the next person knows what they can rely on.