Describe the need before choosing the fix.
A teammate asks for another reminder because estimates are waiting. That request may hide several different problems: the estimate has no owner, the customer needs a revision, or the team cannot find a reply already received. Another message may address none of them.
Start with one observed example. Describe the affected step, what you expected and what actually happened. If you are proposing something new, explain the new need instead of describing the current process as broken.
Keep observation and proposed solution in separate fields. “Three requests have no assigned reviewer” is an observation if your records support it. “Add an automatic reminder” is a proposal. The person reviewing the request should be able to consider a better fix. Use the problem-report guide when the expected behavior itself has failed.
Distinguish a correction from a new requirement.
Fictional example: A repair business has a written process for website estimate requests. Morgan, the office reviewer, should receive responsibility for the first review. The process does not offer appointment booking or after-hours responses.
During a rehearsal, a request appears without a review owner. In the same meeting, somebody asks whether customers could also choose a Saturday appointment through a new chat channel. Both ideas deserve a clear answer, but they are different decisions.
On a small screen, swipe or scroll sideways to read the full table.
| Request | What needs reviewing? | What cannot be assumed? |
|---|---|---|
| Give the estimate request its agreed reviewer. | Compare the ownerless result with the written process. Investigate why the expected assignment is missing. | Whether the cause is known or the correction is covered by a particular service agreement. |
| Add Saturday booking through chat. | This introduces a channel, scheduling behavior and operating responsibilities outside the described process. | That the capability exists, Saturday coverage is available, or the change is included. |
The first is a possible correction to agreed behavior. The second is a new requirement in this example. An unclear request stays unclassified until someone checks the relevant scope and evidence. These labels organize a review; they do not decide contractual entitlement.
Write the smallest complete change brief.
Download the blank change-request brief (CSV). Keep one proposed change per row and link to the relevant internal record. Avoid copying entire customer conversations into another file.
On a small screen, swipe or scroll sideways to read the full table.
| Part of the brief | Example |
|---|---|
| Current agreement and observation | Website estimate requests need Morgan as first reviewer. The rehearsal request has no reviewer. |
| Desired behavior | A new eligible request has the agreed reviewer and a visible review action. |
| What stays unchanged | The inquiry wording, estimate scope and appointment process. No new customer message or booking promise. |
| Open question | Why was ownership missing, and which approved part of the process needs correcting? |
| Acceptance example | An authorized fictional rehearsal shows the right reviewer and action; existing request context remains intact. |
The brief describes a result to assess, not an instruction to alter a live system. Name the person who can decide the request and record any dependency they need resolved first.
Keep the decision separate from the work.
A submitted request has not been approved. A classification says what kind of request it is; it does not authorize implementation. Approval should identify the actual change, its boundaries, responsibilities and any agreed cost or timing before work begins.
Record the decision plainly: clarify, approve the specified work, decline, defer, or request a separate proposal. If only the owner-assignment correction is approved, the chat-booking idea remains separate. Do not hide it inside the same task.
If investigation reveals a different problem or additional work, return that finding to the decision owner. A brief is useful because it makes the boundary visible, not because it prevents new information from changing the plan.
Check the changed behavior and its neighbors.
Before implementation, agree on an observable acceptance example. “Make it better” cannot tell a reviewer whether the change worked. “The permitted reviewer can find the fictional request, see ownership and identify the next action” can.
After approved work, check the changed step and the nearby behavior it could affect. In the example, confirm the request context remains available and that the change has not added an unintended customer message or appointment. Record what was tested, the result and anything not checked.
Use fictional data and a method authorized by the system owner. A live test can send messages or create appointments. The customer-path review checklist helps separate an intended result from an observed one.
Close the request with a usable record.
“Done” should point to the approved change and its check result. Note unresolved items, the next owner and which instructions need updating. A completed configuration change does not establish that customers respond faster or that more jobs were won.
If the request is deferred, keep the reason and the condition for reconsidering it. If the original need was resolved without a change, record that too. A clearer team routine may have been enough.
Bring meaningful unresolved requests into the customer-path review. Choose the next decision from the evidence, rather than letting a list of attractive ideas quietly become promised work.