Triage rules
Version 0.3: the categories, owners and review conditions.
ntwrk/ ntwrk.com.au/how-we-work/sample-decision-pack/
How we work / Sample decision pack
Sample decision pack: triaging incoming requests.
A 30-day POC ends with a decision pack: the evidence, the recommendation and the questions to resolve before further investment. This sample follows one proof of concept, sorting incoming requests, from the question to the recommendation.
Illustrative · synthetic
Illustrative example. Built with synthetic information to show the format. It is not a client result or evidence of performance in your business.
Can a workflow sort requests without skipping a check?
Example Services Co. is a fictional business services company. Every request from its customers and suppliers arrives in one shared inbox. A coordinator reads each one, chooses a category and forwards it to a team.
The team wanted to know whether part of that sorting could be done by a workflow, without losing the checks a person makes today.
The question tested
Can a workflow apply the five agreed categories, suggest the next owner and send uncertain requests to a person, reliably enough on test cases to justify a production build?
What a useful result would look like, agreed before the test
- Routine requests get the agreed category and owner.
- Every request that needs a person goes to a person, even when the workflow’s suggestion looks right.
- Every wrong suggestion can be traced to a cause the team can fix or accept.
- The coordinator can see why each suggestion was made.
How requests are handled today.
This is the part of the current-state map the proof tested. A person makes every decision today. The review point marks the check the business already requires.
How a request moves through Example Services Co. todayIllustrative
Request arrives
By email or web form, into one shared inbox.
Coordinator sorts it
Reads the request and chooses one of five agreed categories.
Sensitive requests reviewed
Complaints, legal matters and personal-information requests go to the customer care lead, who decides what happens next.
Human reviewCoordinator assigns the rest
Forwards each request to the owning team.
Team responds
The team replies and closes the request.
Gaps recorded on the map
- Nothing records why a request went to a team, so a misrouted request is hard to trace.
- Supplier payment questions have no agreed owner. They reach customer billing or finance, depending on who reads them.
- Forwarded email chains often carry an old request above the new one.
What the workflow does, and where a person still decides.
The workflow reads each request and suggests a category, an owner and a short reason. It does not reply to anyone or close a request. Before anything is routed, it checks the review conditions. A request that meets any of them goes to the coordinator, with the suggestion shown as a draft.
Triage rules (excerpt)
| Category | Covers | Owner |
|---|---|---|
| Billing | Invoices, payments, refunds and charges from customers. | Accounts team |
| Service change | New services, changes, moves and cancellations. | Service delivery |
| Account access | Logins, passwords and changes to users. | Support desk |
| Complaint | Dissatisfaction with a service or a person, or a request to escalate. | Customer care lead |
| General enquiry | Questions about the business itself, such as opening hours or locations, from a known sender. | Coordinator |
Send to a person, not the routing rules, when
- two or more categories apply
- the request is a complaint
- the request mentions personal information, a legal matter or a safety issue
- the sender is not in the customer or supplier list
- no category applies.
How to read this
Each row is one agreed category and the team that should own it. The review conditions take precedence: a request that meets any of them goes to a person, whatever category it seems to fit.
Excerpt from the triage rules the coordinator and the customer care lead agreed before the test. The rules are the part of the logic the team can read and change.
The proposed workflowIllustrative
Request arrives
The same shared inbox.
Workflow suggests
A category, an owner and a short reason.
Review conditions checked
Any match sends the request to a person.
Coordinator reviews
Confirms or corrects every suggestion sent for review. Complaints, legal matters and personal-information requests still go to the customer care lead.
Human reviewRouted and recorded
The suggestion, its reason and any correction are recorded.
The answer was agreed before the test ran.
- What was compared
- For each case, the workflow’s suggested category, owner and review decision, against an agreed answer. The help desk’s built-in routing rules were not compared.
- The cases
- Twelve synthetic requests, written to cover routine requests and the hard ones on the current-state map: two categories, missing detail, forwarded chains, complaints and personal information. In a real POC, the team supplies representative requests, kept separate from the examples used to write the rules.
- What counted as correct
- The suggested category and owner both match the agreed answer, or the request goes to a person when the agreed answer says it needs one. A request that needed a person but was routed without one is a failure, even if its category was right.
- Who reviewed
- The coordinator and the customer care lead wrote the agreed answer for each case before the test ran. The customer care lead reviewed every result and the failure notes.
Twelve cases, including the ones that failed.
Each row is one synthetic request. Case 07 is one the workflow must never route by itself. Cases 08, 10 and 12 failed. The cases were written to show each kind of outcome, so the mix says nothing about how often each would happen in practice.
Matched · 5
Sent for review · 4
Failed · 3
Illustrative
| Case | Request | Suggested category | Suggested owner | Outcome |
|---|---|---|---|---|
| 01 | Charged twice for the same invoice. Asks for a refund. | Billing | Accounts team | Matched Agreed category and owner. |
| 02 | Wants to move next week’s service visit to a later date. | Service change | Service delivery | Matched Agreed category and owner. |
| 03 | Locked out after a password reset and needs access today. | Account access | Support desk | Matched Agreed category and owner. |
| 04 | Asks whether the office is open on public holidays. | General enquiry | Coordinator | Matched Agreed category and owner. |
| 05 | Wants to cancel the service and asks for a final invoice. | Service change, Billing | Service delivery (draft) | Sent for review Two categories apply. A person decides the order, as agreed. |
| 06 | Unhappy with a technician’s visit and asks to speak to a manager. | Complaint | Customer care lead (draft) | Sent for review Complaint. It went to a person, as the rules require. |
| 07 | Asks for a copy of all the personal information held about them. | No category | Customer care lead (draft) | Sent for review Personal-information request. It went to the customer care lead, as the rules require. |
| 08 | A supplier asks when an overdue invoice will be paid. | Billing | Accounts team | Failed Wrong category. Billing covers customers only, and the rules have no category or owner for supplier requests, so it should have gone to a person. Rule gap noted. |
| 09 | One line: ‘Please call me back.’ No other detail. | No category | No owner | Sent for review No category applies. It went to a person, as agreed. |
| 10 | A forwarded email chain. The new request, to add a user, sits below an old billing thread. | Billing | Accounts team | Failed Wrong category. The workflow read the old message in the chain. Rule gap noted: read the newest message first. |
| 11 | Asks to add a new user to their account. | Account access | Support desk | Matched Agreed category and owner. |
| 12 | Asks to change a contract term and says they are seeking legal advice. | Service change | Service delivery | Failed Routed without review. The legal mention should have sent it to a person. This blocks production until it is fixed and retested. |
Matched: the suggestion agreed with the answer. Sent for review: the workflow gave the request to a person, as the answer required. Failed: the suggestion was wrong, or a request that needed a person was routed without one.
What the results show
Five routine requests (cases 01 to 04 and 11) matched the agreed answer. Every request the review conditions caught went to a person, including the personal-information request in case 07.
Three cases failed, for three different reasons:
- Case 08. The rules have no category for supplier requests. That is a gap in the process as well as the rules.
- Case 10. The workflow read the old message in the chain.
- Case 12. A legal mention did not trigger a review condition, so the request was routed without a person seeing it. This is the failure that matters most: the workflow must never skip a check the business requires.
What this test cannot tell you.
- Twelve written cases are not a sample of real requests. They show the kinds of outcome, not how often each happens.
- The coordinator’s current error rate was not measured, so there is no baseline to compare against.
- Only English text in the body of a message was tested. Attachments and images were not read.
- Volume, response time and running cost were not measured.
- The help desk’s built-in routing rules were not compared on the same cases.
- The review conditions do not yet cover all legal and safety wording (case 12).
What the team holds, and what the proof depends on.
A decision pack records what the business holds when the proof ends and which services it still relies on. Each of those services has its own terms, access and costs.
Agreed client environment · what the team holdsIllustrative
Test cases and answers
The twelve cases, the agreed answers and the failure notes.
Decision record
Each suggestion, its reason and the reviewer’s decision.
This decision pack
The evidence, the recommendation and the open questions.
Services the proof depends on
- Shared inbox and email service
- Help-desk software
- Hosted model service
- Customer and supplier lists in the CRM
What production would still need.
The proof is not production. A build would be scoped separately, and it would need at least the following.
- A named owner for the workflow, and an agreed owner for supplier payment questions.
- Review conditions that cover legal and safety wording, and forwarded chains read from the newest message.
- A retest on real requests supplied by the team, kept separate from the examples used to write the rules.
- Integration with the help desk, so suggestions appear where the coordinator already works.
- Access agreed for the email service, the help desk and the model service.
- A privacy check of how requests containing personal information are handled and recorded.
- Monitoring: a regular comparison of suggestions with the coordinator’s corrections, and a named person who acts on it.
- A way to switch the suggestions off and return to sorting by hand.
- Operating instructions, and a handover to the coordinator and the customer care lead.
Handover note, triage proof (excerpt)
- Handed over
- Triage rules version 0.3, the twelve test cases with agreed answers, the test results and failure notes, the decision record from the test, and this decision pack.
- Owner after handover
- The customer care lead.
- Open items
- Supplier category and owner (case 08). Forwarded chains (case 10). Legal and safety wording (case 12). Comparison with the help desk’s routing rules.
- Not included
- Production integration, monitoring and support after the proof. These would be scoped separately if a build goes ahead.
How to read this
The note lists what the team holds when the proof ends, who owns it and what is still open. Every open item points back to a test case or a limit in this pack.
Excerpt from the handover note that closes the proof.
Change the process now. Build only if two conditions are met.
- Change the processNow
- Agree who owns supplier payment questions. The gap exists with or without a build.
- BuildOnly if both conditions are met
- After the rules are changed, a retest on real requests sends every request that needs a person to a person, and the help desk’s built-in routing cannot handle the same cases as well.
- BuyIf the retest favours it
- Configure the help desk’s built-in routing instead, if it handles the same cases as well on the retest.
- StopIf a check is skipped
- If the retest still routes a request that needs a person without review.
Questions to resolve before further investment
- Who owns supplier payment questions?
- Which requests, if any, may be routed without a person confirming them?
- Can the help desk’s built-in routing handle the same cases?
- Who will monitor the workflow, and what will they do when its suggestions drift?
Illustrative · synthetic
Illustrative example. Built with synthetic information to show the format. It is not a client result or evidence of performance in your business.