From Questions to Standing Instructions

From Questions to Standing Instructions

A standing instruction tells an intelligence layer to keep analysing a defined situation over a period and to act when conditions are met. Unlike a one-off question, it does not end with an answer. It runs for the duration, watches continuously and triggers a response through connected systems, which turns intelligence into something operational.

The Limit of One-Off Answers

Ask an intelligence layer why customers in one region are unhappy and you get an answer. Good. The transaction is complete.

Now consider the situations where that is not enough. An airline is in the middle of a weather disruption that will run for eleven hours. A bank has launched a product and the first fortnight determines its reputation. A retailer is three days into a recall. In each case there is no single moment when the question is asked and answered. The situation evolves continuously and so does the right response.

A human can handle this by asking the same question repeatedly, which is what war rooms do. It works, and it is limited by how often someone remembers to ask.

“KRC becomes the orchestration layer. Not replacing Genesys. Not replacing Salesforce. Not replacing MoEngage. Sitting above them. Reading from all of them. Acting through all of them.”

Acting through all of them is the part that makes a standing instruction possible. Without connections out to the operational systems, continuous analysis produces continuous notifications, which is just a faster way to create work.

What a Standing Instruction Contains

Four parts, and each is a decision worth making explicitly.

A situation. What is being watched, and for how long. “For the duration of this disruption.” “For the six weeks after launch.” A standing instruction without an end condition becomes an unowned background process, which is how automation accumulates into risk.

A population. Who or what qualifies. Affected passengers. Customers with an open case. Accounts matching a churn pattern. This is usually the interpretive part, because qualification often depends on what people are saying rather than on a field in a database.

A condition. What has to be true for the instruction to fire. The useful ones are judgments rather than thresholds: a complaint theme accelerating among a particular audience, a customer expressing frustration about something specific, a narrative crossing from one community into another.

An action. What happens, in which system, with what limits. Send a message. Raise a case. Suppress a campaign. Flag an account with the evidence attached. Bounded by rate, by target and by whether a human confirms first.

How It Differs from Things You Already Have

Not a workflow rule. Your ticketing system already routes on field values. A standing instruction qualifies on meaning: what the customer is describing, how severe it sounds, whether it matches an emerging pattern. That cannot be written as a field condition, which is why these situations are handled manually today.

Not an alert. An alert notifies a human who then does something. A standing instruction does the something. The difference matters most at volume and at speed, which is precisely when the human path breaks.

Not a chatbot. A chatbot responds when a customer initiates. A standing instruction initiates, based on analysis the customer never triggered.

Not a batch job. It reasons about live conversation rather than executing a fixed computation on a schedule.

Two Situations Where It Changes the Outcome

An airline during a disruption. The instruction runs for the duration of the outage. It keeps identifying affected passengers across every channel, including people who never contacted the airline but posted publicly, and sends lounge access to those who qualify, on WhatsApp, as it finds them. The recovery happens during the disruption rather than in the complaint queue afterwards. The same event produces a retention moment instead of a reputation cost.

A bank with open cases. The instruction is simple and the discipline is rare: no campaign message goes to any customer with an unresolved case. It runs continuously, comparing the case record against the marketing platform’s send list. This prevents the most reliably damaging thing a financial services brand does to itself, which is to send a cheerful cross-sell to someone waiting three weeks for a resolution.

Both are unremarkable as ideas. Both are nearly impossible to run manually, because they require continuous cross-system judgment at volume.

The Governance Question

An instruction that acts unsupervised needs more care than one that reports.

Four principles hold up in practice. Every instruction has a named owner and an end date. Actions are bounded by rate, by target and by class, so no instruction can escalate its own scope. Reversible actions run freely and irreversible ones require confirmation, which is a cleaner line than trying to rank risk. And every action is written into the system that owns the workflow, so the audit trail lives where your security team already looks.

The sensible sequence is to run new instructions in observation mode first, where the system reports what it would have done. A fortnight of that tells you more about whether the qualification logic is right than any amount of design review.

How Konnect Insights Approaches It

Triggers are how this works inside KRC. A standing instruction is defined in plain language, runs against the omni-channel record and the connected systems, and acts through them rather than inside a closed platform. Because the action flows out through MCP connections, the message goes through the channel the brand already uses and the case lands in the system the team already works in.

This is under active development, so the honest statement is about direction rather than a configuration menu. The design principle is the one above: observation first, reversible actions before irreversible ones, named owner, defined end.