Channel
Which door is open — email, a ticket portal, a request forwarded from an existing PSA, or a phone line staffed by an authorized contact? Fewer channels are easier to secure and audit.
Design the front door before requests start arriving.
Intake is the first place a lane can go wrong. A workable design names the channel, checks who is asking, classifies the request, and routes it — before volume makes the gaps expensive.
Six decisions the intake design has to make.
Displayed identity
What name and identity does the requester see? This should match the client-experience decisions already made for the lane, not be improvised per channel.
Authorization check
How is the requester confirmed against a named list of authorized contacts — not judged by tone, urgency, or a familiar-sounding name.
Required information
What has to be present before work starts: affected user, business impact, and the outcome the requester expects.
Classification
Which request family does this match in the service catalog, so routine work and exceptions are not handled the same way by accident.
Routing
Where the request goes next — the standard queue, a specific request family, or straight to the exception path when nothing written covers it.
Follow one request from arrival to routing.
The request arrives
It enters through the agreed channel, with the identity and language matching the client-experience design for this lane.
Useful input: the channel it was expected to use, not an improvised alternative.
The requester is checked
The name is compared against the authorized-contact list recorded in the service profile. Unclear authority stops here rather than proceeding on trust.
Possible output: accepted request, or a short confirmation ask back through the agreed channel.
The request is classified
It is matched against a service-catalog family, or marked unmatched when nothing written describes it.
Possible output: a classified request, or an item routed straight to the exception path.
The request is routed
Classified work enters the standard queue for that family. Unmatched work enters the exception procedure instead of being quietly absorbed.
Recorded result: a request record with enough context for whoever picks it up next.
Who designs each intake decision.
| Channel and identity | Selling practice decides, since it is part of the client-facing promise. |
|---|---|
| Authorized-contact list | Both — the client confirms names, delivery maintains and applies the list. |
| Classification rules | Delivery proposes them against the written service catalog; the selling practice confirms fit. |
| Escalation trigger | Agreed together and recorded in the escalation matrix before the first request arrives. |
Test the design before requests depend on it.
- Can an authorized request reach the right queue without a phone call to confirm it?If not, the classification rules are not specific enough yet.
- What happens to a request from an unlisted sender?A workable design has an answer, not a shrug.
- Can classification be done without guessing at intent?Vague categories push judgment calls onto whoever is busiest.
- Does an unmatched request have a clear next step?It should never simply sit unassigned.
Once intake is designed, decide who owns the exceptions it produces.
An intake procedure only works when everyone already knows who decides on the requests it cannot classify.