Resolve

Behaviour you write down, not behaviour you hope for.

A scenario is a case definition: when it applies, what Scout collects first, what it is allowed to do, what it must never do, and when it hands the conversation to a person. Five clauses, in plain language, reviewed by a human and versioned like code.

Book a demo See the limits that sit on top

A scenario called Order status is written line by line — when it applies, what to collect, what to do, what never to do — and then a live message arrives and is matched against it.

Illustrative demo with fictional data.

Anatomy

Five clauses. That is the whole format.

Each one answers a question a team lead already answers in training. Writing them down is the only change.

Applies when: The situations this scenario covers, in the customer's words. “Asks where an order is, or gives an order number.” Scout matches against this, and the match score is recorded in the run.
Collect first: What Scout must have before it does anything. An order number, a phone number, a booking reference. If it is missing, you say what happens: ask once, then hand over.
Then do: The tools it may call and what it may say about the result. “Run Look up order. Quote the status and the delivery window it returns.” Scout cannot reach for a tool this clause does not name.
Never: The things that are wrong even when they would make the customer happy. Promise a date the tool did not return. Offer a discount. Confirm a refund. These are checked before a reply leaves.
Hand over when: The exit. An order more than three days late, an angry customer, a request for a person. The whole thread goes with it, including what Scout already looked up.

A scenario is a document a non-engineer can read in thirty seconds and argue with. That is the point of it.

Why not a prompt

A paragraph cannot be reviewed, diffed or rolled back.

Most tools in this category give you one large instruction field and call it configuration. It works until two people edit it, or until a reply goes wrong and nobody can say which sentence caused it.

Separable: Order status, returns and damaged-item complaints are three scenarios, not three sentences competing inside one paragraph. Changing one cannot quietly change the others.
Reviewable: A scenario has an author, a version and a diff. You can see that someone removed “hand over when the order is late” last Tuesday, and who approved it.
Attributable: Every run records which scenario matched and at what score. When a reply is wrong you are reading a named clause, not guessing at a paragraph.
Testable: Because a scenario names its expected behaviour, an evaluation can check it. A prompt has nothing to check against.

One instruction field

You are a friendly support agent for Nile Home. Be helpful and concise. If the customer asks about an order, look it up. Don't promise delivery dates. Be nice about refunds but don't commit. Escalate if they're upset…

Five named clauses, per case

1Applies when
2Collect first
3Then do
4Never
5Hand over when

At runtime

Matched, not improvised.

A message arrives. Scout scores it against your published scenarios and takes the best match above your threshold. The chosen scenario, its score, and the clauses that fired are all written into the run.

Above the threshold: The scenario runs. Its “Then do” clause is the only set of tools Scout can reach for in this conversation.
Below the threshold: No scenario is forced. Scout falls back to answering from approved knowledge — and if it cannot cite a source, it hands over.
Two close matches: Scout does not blend them. It takes the higher score and records the runner-up, so you can see where your definitions overlap.
Nothing matches: The conversation goes to a person with the context already attached. A silent guess is never the fallback.

Every one of those outcomes is a row in the run trace.

See what a run trace contains

Before it ships

Rehearse the scenario against conversations that already happened.

A new scenario is a draft until a person publishes it. While it is a draft you can run it in the playground against real past conversations and read what it would have said, next to what your team actually said.

Playground: Type a message, or load a past conversation, and watch the draft version run end to end — scenario match, tools, guardrail checks, draft reply.
Side by side: The draft version's answer sits next to the live version's answer. You are reading a diff, not a demo.
Publish is an event: Publishing creates a version with an author and a timestamp. Rolling back is selecting an earlier one.
Scored, not vibed: Before a version goes live you can replay your whole evaluation set against it and see whether anything got worse.

How evaluations score a version

Scenarios and guardrails

A scenario says what to do. A guardrail says what can never happen.

They are different objects on purpose. Scenarios are per case and there are many of them; guardrails are workspace-wide and there are few. A guardrail holds even when a scenario — or a clever customer — asks for something else.

Scenario

Per case. Written by whoever owns that case. Says: when this happens, collect this, do this, never this, hand over then.

Guardrail

Workspace-wide. Owned by whoever is accountable for money and claims. Says: this tool is off, this amount needs sign-off, this sentence never leaves.

Guardrails are evaluated after the scenario decides and before anything executes. A scenario cannot grant itself permission a guardrail withholds.

Read the guardrails page

Questions

About scenarios

How many scenarios does a team usually need?

Fewer than people expect. Most of the volume on a messaging channel is a handful of repeated cases — where is my order, is this in stock, how do I return it, do you deliver here. Start with the four you answer most and let everything else fall through to a person.

Who writes them?

Whoever already writes the training notes. A scenario is five plain-language clauses; it does not require an engineer. Tools and integrations are configured separately, once, by someone with access to your systems.

What happens when two scenarios overlap?

Scout takes the higher match score and records the runner-up in the run. Overlap shows up in your traces as near-ties, which is the signal to split or merge the definitions.

Can a scenario call our own system?

Yes, if you have configured that tool and named it in the scenario's “Then do” clause. Scout cannot call a tool a scenario did not name, and a guardrail can switch any tool off for the whole workspace.

Does changing a scenario affect conversations already running?

Publishing creates a new version. Conversations in flight finish on the version they started on, and the version used is recorded in each run, so a trace from last week still explains itself.

Bring your customer conversations together.

Tell us a little about your team. We'll show you how BlendDesk could fit the way you already talk to customers.

Book a demo Talk to us