Policies

What is a Policy?

A policy is one rule of your business, written in plain language, that the AI is allowed to answer from: how you handle returns after 30 days, whether a customer can change the delivery address after dispatch, what you say when an order is delayed.

You describe the situation and what should happen. The AI finds the policy by itself when a customer raises that situation, and answers according to it.

It helps to keep three things apart:

• Articles are facts a customer could read for themselves.
• Policies are decisions your business has made, and the AI's mandate to act on them.
• Workflows are step-by-step procedures with tools and checkpoints, for cases where "answer well" is not enough.

Policies live under Knowledge → Policies. There is also a template library of common ones (returns, cancellations, address changes) you can install and then edit.

How the AI finds a policy 🔎

The AI does not read your policy list top to bottom. For each customer message it runs a semantic search over your policies and takes the best matches.

What it searches is more than what you typed. When you save a policy, we generate a set of example questions and short search phrases in every language your markets use, and index those alongside your description and tags. That is why a policy written in English still matches a customer writing in Danish or German, and why phrasings you never thought of still find it.

Then, for each candidate:

• Policies that are switched off, or outside their validity window today, are dropped.
• Ticket rules are evaluated against this specific conversation. A policy whose rules do not match is dropped.

Whatever survives is handed to the AI as the guidance it must follow for that reply. If nothing matches, the AI falls back to your articles and its general instructions.

Note: matching is driven by the description, not the name. A policy named "Returns" with a two-line description will be found less reliably than one that spells out the situations it covers.

Anatomy of a policy

The editor has up to six tabs.

Details

• Active, the on switch. Off means the AI never sees it, immediately.
• Name (required), for your own overview.
• Description (required), the policy itself. This is the important field: it is both what the AI matches on and what it follows. There is an AI assist button that suggests phrasings.
• Valid from and Valid until, optional. Both are inclusive whole days. Leave them empty for a policy that always applies.
• Tags, optional, useful for unusual terms that should help retrieval (product names, campaign names).

Rules

Conditions that must hold for the policy to be usable at all. See "Ticket rules" below.

Examples

Example responses that show how a reply under this policy should read. They teach tone and shape, not facts.

Advanced

• Response method, what the AI is allowed to do with this policy. See below.
• Agent tools, the tools the AI may use while acting on this policy, for example an order lookup or a cancellation tool.

Custom prompts

Extra instructions appended to the policy only when their own rules match. This is how one policy covers several markets or customer types without becoming a fork: the base description stays the general rule, and a custom prompt adds "in Germany, offer a prepaid label" on top.

URLs

Appears when your description contains links. Any URL can be given a per-market equivalent, so the same policy points at the Danish page for Danish customers and the Swedish one for Swedish customers.

Response method: draft, semi, fully automated ⚙️

Every policy states how far the AI may go on its own:

• Draft 📝 Writes a draft for an agent to review and send. Nothing reaches the customer by itself.
• Semi-Automated 📨 Sends the reply and leaves the conversation open.
• Fully Automated ✅ Sends the reply and closes the conversation.

This is a ceiling, not a guarantee. Your team and agent configuration can cap automation independently, and the strictest setting always wins. A Fully Automated policy running under a drafts-only agent produces a draft, and no side effects are fired.

The safe way to launch a new policy is Draft, read a handful of real drafts, then raise it.

Ticket rules 🎯

Rules narrow a policy to the conversations it belongs to. A policy with no rules is eligible everywhere, which is the right default for most.

You can build conditions on:

• The conversation: market, channel, source (an imported third-party ticket is not the same as a plain e-mail), subject, sender address, the first message body.
• The order, when an order integration is connected: status, dates, amounts, whether an order was found at all, split shipments.
• The customer, including whether they have an account, and Shopify metafields.
• Your own custom fields.

Conditions can be grouped with AND and OR. Typical uses: a market-specific returns rule, a policy that only applies when an order actually exists, or one restricted to chat.

Time-limited policies 📅

Valid from and valid until make campaign and seasonal rules safe to write in advance. Set the window and the policy switches itself on and off: the AI ignores it before the start date and stops using it the day after the end date. Nothing to remember, and no risk of an extended Christmas return window quietly applying in March.

Switching off and deleting

Untick Active and the policy leaves the AI's index right away. That is the fastest correction when a policy is producing wrong answers, and it keeps the text so you can fix and re-enable it.

Deleting is blocked while a policy is attached to an agent or referenced by a workflow. The error names what is using it. Detach it there first, or just deactivate instead.

Writing policies that work

• One decision per policy. "Returns, exchanges and refunds" retrieves worse than three focused policies, and is harder to change later.
• Describe the situation, then the answer. The first half is what retrieval matches on; the second half is what the AI follows.
• Be concrete about limits and numbers. "Within 30 days of delivery, unused, original packaging, customer pays return shipping" leaves nothing to invent.
• Say what to do when the condition fails. Most bad answers come from a policy that covers the happy path only.
• Name the escalation. If a case should go to a human, write that into the policy.
• Do not repeat article content. Link the facts, keep the decision in the policy.
• Avoid two policies that answer the same question differently. When the AI suggests a new policy from a real conversation, we check it against your existing ones and flag conflicts, but hand-written policies are on you.

Good to know

• Each policy row has a Runs button that shows every AI run which used it. That is the quickest way to see a policy's real behaviour instead of guessing.
• Tags you add are yours; the AI also generates its own tags and question variants in the background right after you save. Give it a moment before judging retrieval on a brand new policy.
• Example responses shape tone. If replies feel off-brand, add two or three good ones rather than rewriting the description.
• Editing a policy takes effect on the next conversation. There is nothing to publish or rebuild.
• Policies are per team, and the same policy can serve every market unless its rules or custom prompts say otherwise.