Layer 1
Deflect where the request is born.
Why deflection is a per-channel design problem — and a working build for the one place with the most leverage: the record producer itself.
← Part 2: Read the Instance Before You Design the Agent
Layer 1 has one job: resolve the request in the channel, before a record exists. What resolves here never becomes a ticket, never gets routed, never gets reassigned, and never needs a category. It is the cheapest work in the entire pattern — and in every environment we have looked at with a customer, it is the least developed.
A note on numbering before we start, because it trips people up: this is Part 3 of the series and it covers the first of the three layers. Parts 4 and 5 cover Layers 2 and 3.
This part has two halves. First what the data says, because the diagnosis is remarkably consistent. Then a build, because we got tired of describing this one and decided to make it importable.
The same four findings, again and again
We have worked through the method from Part 2 together with customers in different industries, with no shared history and no shared implementation partner between them. Each time it was their data, their environment and their team in the room. The Layer 1 findings barely differ.
| Finding | What we saw |
|---|---|
| Self-service is the largest human channel | Roughly a third of all volume enters through the portal — more than phone, chat, email and walk-in combined |
| The catalog is wide and idle | Around three quarters of active catalog items are unused or barely used — hundreds sitting at exactly zero requests over 180 days, while a couple of hundred items carried nearly all the volume |
| Users type keywords, not questions | Of tens of thousands of portal searches, close to 60% were a single word — “sap”, “vpn”, “cmdb” — and roughly 1% were a full question |
| Nothing is measured | Deflection rate: unknown. Not low — unknown. There was no running baseline to compare anything against |
Put those together and the mechanism is obvious. The largest human channel is a form-first experience. Nothing on the way in tries to answer the question. So every visit that starts with a problem ends with a freshly created record — and because it was never measured, nobody experienced this as a failure.
Before any build: decide what deflection means on your instance and start recording it. A deflection programme without a baseline cannot be evaluated, defended or funded. This costs configuration time and no development effort, and it unblocks every later conversation.
Deflection is a per-channel design, not a feature you switch on
This is the most common mistake we see, and it is an expensive one because it looks like efficiency. One deflection strategy pointed at every channel underperforms in all of them, because the channels are not variations of each other — they have genuinely different physics.
| Channel | What deflection actually means here |
|---|---|
| Self-service & catalog | Resolve or pre-qualify on the way in. The item itself either answers the question or collects enough that nobody has to ask back |
| Chat / virtual agent | Answer inside the conversation. The user is already in a dialogue — the hard part is topic coverage, not interaction design |
| Voice | Same intent logic as chat, but in real time and with no visual fallback. The intent model is reusable; the experience is not |
| Email & free text | Arrives largely unstructured. Deflection here is mostly recognition and reply, and it is the channel most often left alone entirely |
| Monitoring & alerts | Already structured at source. There is no human to deflect. This belongs to an automation track, and counting it as a deflection miss distorts every rate you publish |
| Walk-in | Small in volume, disproportionate in perception. Usually better addressed by fixing the channel people avoided |
Sequencing follows from your own channel mix, not from ours. If a third of your volume arrives through the portal, that is where the first design goes — regardless of which channel is currently more interesting to talk about.
This is the trap waiting for Jonas from Part 1, and it is an easy one to walk into. The tempting first build is the channel that is most interesting to work on. The defensible first build is the channel carrying the volume — and having this table to hand is what lets him say so to Miriam without it sounding like a preference.
Why catalog cleanup is not housekeeping
Deactivating hundreds of unused catalog items reads like a tidy-up ticket that gets deprioritised for two years. It is actually a prerequisite, for one reason: a smaller catalog produces better search results.
Every abandoned item, every duplicated variant, every uncategorised leftover is a candidate that search has to rank and reject. Retire them and the surface that AI Search reasons over gets sharper for every remaining item. A realistic target is often around two thirds of the currently active items — and that reduction is the cheapest quality improvement available anywhere in the layer.
The same applies in reverse: activating intelligent search over a catalog that is three quarters dead will underperform, and the conclusion drawn will be “search does not work here.” Order matters.
The highest-leverage place: inside the record producer
Here is the specific gap that bothered us most. A user opens the general “get help” record producer. They type a free-text description of their problem. They press submit. At no point between typing and submitting does anything try to help them — even though the moment they finish typing is the single best-informed moment in the entire interaction. The system now knows exactly what they want, in their words, and it has not yet created anything.
So we built something for that moment. Internally we call it TT-QualityCoach. It sits on the free-text field of any catalog item or record producer and does two things at once.
Figure 1. What actually gets typed. Seven words, two typos, no category, no reason, no date — and the submit button is right there.
Figure 2. What comes back. The dedicated catalog item is surfaced first — that is the deflection. Everything below it is the pre-qualification path: category, readiness, the two facts that are missing, and a rewrite the requester can insert with one click.
Two parallel paths, and that is the whole trick
Two seconds after the user stops typing — or on an explicit button press — the widget fires two independent server calls at the same time:
Search, no language model
- What
- Plain AI Search across catalog items and the knowledge base. No generative call in the path at all.
- Why
- Result cards appear almost immediately. If an offering or article already exists, the user is pointed at it and the free-text request is never submitted — textbook deflection.
Coaching, with a language model
- What
- The search results, the free text, requester context and the current catalog item all go to a Now Assist skill. It judges category and completeness, detects whether this is actually an incident, proposes a concrete rewrite, and re-ranks the search results by real relevance.
- Why
- When deflection does not fully land, the free text itself gets good enough that the fulfilment team can work it without asking back.
Parallel, not sequential. The user sees the fast cards straight away while the language model is still working; the coaching panel appears afterwards and quietly reorders the cards it has now actually read. That is how the experience stays responsive despite generative latency — and it is the design decision we would most encourage you to copy, whatever you build.
No configuration per catalog item
The client script finds the free-text field itself, by scanning the rendered form for text areas and applying a priority list of common field names. That was a deliberate choice: a feature that has to be wired up per catalog item does not get rolled out across a thousand of them. Drop the widget on the page and it works.
Context is what stops the advice being generic
The skill receives the name and short description of the catalog item the widget is sitting on. Without that, “I need it urgently” is uncoachable. With it, on a specific software request item, the same three words are correctly read as an urgent request for that software — and the widget stops circularly suggesting the very item the user is already standing on.
Two technical markers, stripped before display
The skill ends its response with [[INCIDENT: yes/no]] and [[RANKED_IDS: 3,1,2]]. The first drives an escalation button when the request is really a broken-thing report rather than a service request; the second reorders the search cards. Both are removed before anything is shown.
If you build with end-of-response markers like these, set your token limit generously. A limit that is slightly too tight truncates the response before the markers — and the failure is silent and deeply misleading. It looks exactly like the model failing to detect an incident, when in fact it detected it correctly and the answer was cut off. We lost time to this.
Reusable across domains by configuration
Which skill to call, what search scope to use and where to escalate are held in a small configuration table rather than in the widget. The intent is that a second domain — HR, facilities, customer service — is a configuration record and a prompt, not a second widget.
In the interest of honesty: we have built and run this for IT. The additional-domain path is designed and not yet demonstrated. Treat it as an architecture claim, not a delivered feature.
What is in the package
| Component | Role |
|---|---|
| Service Portal widget | Template, client script and server script — UI plus orchestration of the two parallel calls |
| Now Assist skill configuration | Wraps the generative call as a reusable capability |
| Prompt configuration | The instructions, including the marker contract |
| Coaching profile table | Per-domain configuration: skill, search scope, escalation target |
| Search context and profile | Defines what the fast path is allowed to search |
| Access controls, application menu, escalation record producer | The supporting furniture, so the import is usable rather than just present |
Update set: TT_QualityCoach_Complete_CLEAN2.xml — import, preview, commit. Expect preview warnings on references to organisation-specific categories and users; those are normal between unrelated instances and safe to accept. Be more careful with anything referencing a core container object — skip those rather than overwrite your own configuration.
Demo-grade MVP. No warranty, no support, no upgrade path. Non-production instances only. Read it, break it, rebuild it better — that is what it is for.
Known limits — and where this actually runs
Start with the honest one, because it matters more than the technical caveats. What you are looking at is a demo-grade MVP — built, committed and stable on demonstration instances, and nothing more than that. It is not a ServiceNow product, not on any roadmap, not supported, and not a production deployment carrying real user volume at an enterprise. We are not going to imply otherwise by staying quiet about it.
So take the architecture and the design decisions seriously — those are the transferable part, and they are the reason we wrote this down. But do not take any deflection figure from us for this build, because there is not one to give. We hold ourselves to the rule from Part 2: a number is either measured or it is not claimed. This one is not measured yet.
Beyond that:
- Field detection is heuristic. A heavily customised form with unusual markup may need the priority list extended.
- The fast path is only as good as what is indexed. If AI Search is not active, Path A returns nothing and you are running Path B alone — which works, but is not deflection.
- The coaching quality is prompt-bound. Expect to iterate on the prompt against your own category set; ours is tuned to ours.
- The additional-domain path via the coaching profile is designed and not yet demonstrated, as noted above.
Where Layer 1 hands over
The coaching path is worth looking at once more, because it is not really deflection. Deflection is Path A: the request never happens. Path B is pre-qualification — the request does happen, but it arrives with a sensible category, complete information and a clean description.
That is Layer 1 doing part of Layer 2’s job at the cheapest possible moment, while the user is still present and can answer. Anything qualified at intake is something the gatekeeper in Layer 2 does not have to ask back about — and asking back after submission is the most expensive question in service management.
Which is exactly where Part 4 picks up: the gatekeeper itself. Small, cheap, deliberately narrow, a fixed set of approved categories, five possible outcomes — and buildable today.
The series
| Part | Topic | Status |
|---|---|---|
| 01 | One flow, three layers — the pattern | Read now |
| 02 | Read the instance before you design the agent — harvest, filter, score, visualise | Read now |
| 03 | Layer 1 — deflect where the request is born, including a working build to import | You are here |
| 04 | Layer 2 — the gatekeeper you can build today | Read now |
| 05 | Layer 3 — specialists scoped to a category, not a team | Next week |
| 06 | Six things that bite you when you build this | Next week |
Tell us where we are wrong
If you import this and it breaks, say so in the comments and we will update the article. If your channel mix looks nothing like the one above, we would genuinely like to know — a handful of instances agreeing is a pattern, not a law.
Views are our own and do not represent our team, employer, partners, or customers. Anything we build and share in this series is a demo-grade MVP — not a ServiceNow product, not part of any roadmap, and not supported. The update set is shared as-is, for evaluation on non-production instances only.
