Prompts, instructions & policy

This page covers the two steps of the bot wizard where you tell the bot what to say and how to behave:

• Step 1: Instructions — the system prompt, per-call runtime context, post-call analysis, quality control, and auto dispositions.
• Step 2: Policy — the optional conversation policy engine for collection and motor-insurance-renewal calls.

Both steps live inside the bot creation wizard. If you haven't seen the wizard yet, read Create a bot first. The voice engines and call tools are covered separately in Voice pipeline and Tools & integrations.

How variables work

Throughout these steps you will write {{variable}} tokens. At call time the platform replaces each token with a real value (a customer name, an amount, today's date). Variables come from a handful of named sources called namespaces.

You can also write a flat token without a namespace, which is convenient when ops owns the column names:

Hello {{CUSTOMERNAME}}, your pending amount is {{due_amount}}.

A flat token first tries an exact match, then strips the prefix and searches a fixed, limited order: system. → crm. → call..

Step 1: Instructions

This step is where you write the bot's brain: the standing instructions it always follows, the fresh context it gets for each individual call, and the prompts that run after the call ends to summarise and score it.

The two prompt fields

The bot's instructions are split into two boxes on purpose. The split lets the platform reuse the unchanging part of your prompt across every call, which keeps calls fast and cheap.

A worked example of how the two fields combine:

You are Kavya, a polite collections agent for Acme Finance.
Speak in Hindi, switch to English only if the customer does.
Never threaten the customer. Always offer the payment link if they agree to pay.

Customer: {{crm.CUSTOMERNAME}}
Total due: {{crm.total_due}}
Days past due: {{crm.dpd}}
Today's date: {{system.current_date}}

Post-call analysis

After the call ends, the platform can run the transcript through a language model to produce a structured summary (disposition, intent, notes). Use the collapse/expand control on the Post-Call Analysis section header to show or hide these fields.

Using a different model for post-call work

Live calls run on a fast, low-latency language model. Post-call analysis and quality control don't need to be fast, so you can optionally run them on a slower, higher-accuracy model. Toggle Use a different model for post-call analysis to reveal the override fields.

Quality control (QC)

The Quality Control section (use its collapse/expand header to show it) lets the bot score each call against criteria you define.

Auto dispositions

Not every call reaches the analysis model — very short calls, calls where the customer never spoke, voicemail, timeouts, and system errors are dispositioned by rule instead. The Auto Dispositions section (use its collapse/expand header) lets you map each of those conditions to the disposition values your CRM expects.

For each condition you can set up to three text values:

The conditions you can map:

Buttons on this step

The wizard's Previous, Continue, and Cancel controls live in the shared wizard footer and behave the same on every step — see Create a bot.

Step 2: Policy

The policy step is an optional guided alternative to writing a system prompt by hand. Instead of free-form instructions, you fill in a structured form — company name, agent name, CRM field names, payment details — and the backend assembles a tested, compliance-aware system prompt for you at call time. It is purpose-built for two India-specific call types: loan collections and motor insurance renewals.

Turning it on

Template and identity

Collection-specific fields

These appear when the template is any of the four Collection types.

Insurance-renewal-specific fields

These appear only when the template is Insurance — Motor Renewal.

CRM field mapping

Your CRM's column names rarely match the names the policy expects. This section maps each policy field to the raw column name in your data, so the bot can quote real figures to the customer. The list of fields shown depends on the template.

Compliance scenarios

These toggles arm the bot with safe, pre-written handling for sensitive situations. Which ones appear depends on the template.

Each scenario is an independent on/off toggle — enable the ones your compliance team requires.

Redial context

When you call the same customer more than once, this section lets the bot open differently based on what happened last time.

A small example:

{
  "promised_to_pay": "Gently remind the customer of their earlier promise to pay.",
  "wrong_number": "Apologise briefly and confirm you have reached the right person.",
  "asked_callback": "Acknowledge that the customer asked to be called back at this time."
}

Buttons on this step

As on every step, Previous, Continue, and Cancel live in the shared wizard footer.

Where these settings show up later

• The values flow into live calls as the bot's instructions and as {{crm.*}} / {{call.*}} / {{system.*}} variables.
• The fields you define in the analysis and QC prompts become {{analysis.*}} and {{qc.*}} variables you can push to your CRM — configure that in Tools & integrations.
• Once the bot is created, you can edit any of these fields again from the bot detail page — see Bot detail.
• Before going live, place a test call to hear the opening and confirm variables resolve — see Test calls.