Start with an operational decision
A routing rule should answer three questions: what work arrived, who can act on it, and how soon does that action matter? A channel name or a keyword is only an input. Do not make a broad match such as “refund” equivalent to a confirmed incident. Use an explicit review stage when the information is incomplete.
Write the intended action before configuring the trigger. “Assign a billing review to customer operations” is useful. “Make this important” is not specific enough to guide either a responder or a test. Keep the vocabulary readable by the people who will handle the queue.
Use three clear destinations
| Destination | Meaning in this example model | Expected next step |
|---|---|---|
| Urgent | A time-sensitive issue with an available responsible role | Ask that role to accept and act |
| Queued | Work requiring a reply or investigation during staffed review | Assign an owner and a review window |
| Digest | Informational updates without an immediate requested action | Group for planned reading |
These are planning definitions, not service guarantees or universal severity standards. Adjust them to the actual team and document the change. A one-person business and a staffed operations team should not inherit the same coverage assumptions.
Write positive and negative examples together
Consider an illustrative rule for a possible checkout issue. A new report of repeated checkout failure enters support review. A report already tied to confirmed broader impact may qualify for the urgent route. A message saying that a prior failure is fixed should not create the same initial escalation.
Include an ordinary inquiry, a repeated event, a quoted historical problem, an unknown sender, and a missing field in the test set. Where a match is ambiguous, record the ambiguity rather than inventing certainty. The general notification guide shows this decision process in a worked example.
Keep a compact rule record
{
"example_only": true,
"rule_name": "active-booking-access-review",
"source_scope": "authorized business conversations",
"condition": "reported access issue for a current booking",
"first_action": "human review",
"owner_role": "active event support",
"default_destination": "queued",
"urgent_when": "impact confirmed and staffed responder available"
}
This is an illustrative planning record, not an InstaPager API request or a provider payload. It intentionally contains no credentials, customer details, or executable connection instructions.
Preserve identity and review history
Record the source event reference, the routing reason, and the rule revision used for a decision. A repeated delivery should not create an unrelated second task. Group by the actual issue where the context supports it, and let reviewers split an incorrect grouping.
Each rule needs an owner, a review point, and a reversal procedure. Temporary event rules should be retired after the event. When you change a condition, update its negative examples at the same time. Compare the resulting queue with the original expectations rather than measuring success only through notification volume.
Your next step
Choose one channel from the channel directory, write three fictional messages, and ask the intended responder to classify them. Resolve disagreements before connecting a receiving process. Then use the escalation guide to define acceptance, backup ownership, and completion.