Skip to main content

Overview

Protocols are how you teach your AI Agents to resolve tickets according to your business processes. Each protocol covers one scenario — how to handle it, which integrations to use, and what to tell the customer. If a scenario isn’t covered by a protocol, the agent won’t know how to answer it, so aim to cover every situation that can come up in your support. For e-commerce that usually means returns, cancellations, exchanges, order status, complaints, damaged products, and more.

Training Center

Protocols live in the Training Center, organised into bases and categories. Bases
A base is a collection of categories and protocols that you assign to an AI Agent. The base determines which processes that agent follows.
Categories
Categories group related protocols. Each category should have a clear, self-explanatory name, and categories should be mutually exclusive. Common categories:
  • Orders, Shipment & Delivery
  • Returns, Cancellations & Exchanges
  • Products
  • Payments & Invoices
  • Subscriptions (for subscription businesses only)
  • Account
  • Complaints, Defects & Warranty
  • Other
Feel free to deviate from this structure if another split fits your business better. Templates and best practices are further down this page.

Writing protocols with the AI Manager

Create a protocol with the Add protocol button inside a category. The easiest way to write one is by talking to the AI Manager — just tell it what the protocol should cover, in any language. For example:
  • Help me write a protocol about returning orders
  • I want a protocol for customers asking where their package is
The AI Manager asks follow-up questions and drafts the protocol with you. Be as detailed and specific as possible — tell it which system each piece of information comes from (for example, “if the order was fulfilled more than 4 days ago according to Shopify, then…”) and think through every scenario and edge case. The more complete the protocol, the better the agent performs.
The AI Manager is deliberately a quality gatekeeper. It may push back, ask sharp questions, or suggest that your content belongs in a different protocol, in Rules, or in Tone of Voice instead. This keeps your protocol library clean and non-overlapping.
After the AI Manager drafts a protocol, review it carefully before saving — it can make mistakes. To change something, just describe the edit; the AI Manager will show you the proposed change before you save and publish. You can also edit any protocol by hand: click into it to open a simple text editor, then save and publish your changes.
Ask the AI Manager for gaps and improvements in your protocols. It can learn from your real ticket history to point out missing scenarios and suggest where automation is safe to enable.

Referencing integrations and actions

Inside a protocol, refer to integrations in plain language — for example, “retrieve the order status from Shopify”. You can only reference integrations that are actually connected to the base. To let the agent do something (not just look things up), reference an action using the forward-slash (/) command in the editor and picking the action you want, such as cancelling an order or updating an address. See Actions for how actions are set up.

Activating and automating protocols

Each protocol has two toggles:
  • Active — when on, the agent can use this protocol. When paused, the agent ignores it even if it’s part of a connected base.
  • Automated — when on, the agent can send replies for this protocol automatically. When off, it drafts a suggestion for your team instead.
Actions have their own automation toggle per protocol. An action only runs automatically when both the protocol and the action are set to automated (and global automation is enabled). If the protocol is automated but the action isn’t, the agent will propose the action and wait for a human to approve it.
When a customer message covers multiple topics, the agent needs a protocol for every topic mentioned. If even one topic lacks a protocol, the agent won’t send an automated reply.

Escalating to a human

Within a protocol you decide exactly when a ticket should be handed to a human. There are two ways to escalate:
  • Silent escalation — the agent sends no message and leaves the ticket open for your team to pick up.
  • Escalate with a message — the agent sends a short holding reply (for example, letting the customer know a specialist will follow up) and then leaves the ticket for a human.
Tell the AI Manager exactly when each type should happen and it will add the right escalation points; you can also add them manually with the / command in the editor.
Escalate sparingly. Before adding an escalation, ask: can the protocol simply answer the question, or resolve it with an action? Only hand off to a human when that’s genuinely the right outcome — over-escalating means more work for your team and slower replies for customers.

Best practices

Use this checklist for every protocol:
  1. No mistakes or impossible steps. Don’t reference actions or data the agent can’t actually access.
  2. Cover every case. A “Returning Orders” protocol should handle all reasons for returning, all time windows (e.g. delivered more than vs. less than 30 days ago), multiple items in one package, a lost return form, and so on. (A customer asking for their return status is a different scenario and belongs in its own protocol.)
  3. Don’t contradict other protocols. Keep the whole library MECE — mutually exclusive and collectively exhaustive.
  4. Be explicit about which integration provides which information.
    Bad: “if the order has been returned then…”
    Good: “if the order has been marked as returned in Monta, then…”
  5. Keep each protocol self-contained. Protocols can’t reference each other, so if two scenarios share steps (for example a damage complaint that ends in a return), include those steps in both protocols.
  6. No tone or general rules in protocols. Tone of voice and always-on do’s and don’ts belong in your AI Agent settings, not in a protocol.

What protocols should I write?

Cover every scenario that can arise in support. If a protocol is missing, the agent won’t answer messages about that scenario. Keep protocols non-overlapping (MECE) — for example, instead of separate “returning product a” and “returning product b” protocols, write one “returning order” protocol that covers both. For a typical e-commerce store, we recommend the following categories and protocols:
  • Orders, Shipment & Delivery
    • Order and Shipment Status — order confirmation delays, processing timeframes, shipment notifications, tracking number issues, delivery date estimates, backorder communications, split shipment explanations, carrier delays, and proactive status updates.
    • Package Not Delivered — tracking shows delivered but the customer hasn’t received it: verification steps, carrier investigation, theft reporting, neighbour/safe-place delivery checks, and replacement/refund timelines.
    • Partial or Incomplete Delivery — missing items in a shipment: inventory verification, item tracking, dispatch of remaining items, compensation for delays, and communication about separate arrivals.
    • Cancelling or Modifying Orders
  • Returns, Cancellations & Exchanges
    • Returning Product — return eligibility, condition requirements, return windows, return authorisation, prepaid labels, packaging requirements, inspection, and processing timeframes.
    • Status Return & Refund — return shipment tracking, receipt confirmation, inspection status, refund stages, payment-method-specific refund timelines, partial refunds, and failure resolution.
    • Exchanging Product — size/colour exchanges: availability checks, price-difference handling, exchange shipping, return of the original item, and timelines.
  • Complaints, Defects & Warranty
    • Damaged Product on Arrival — damage assessment, photo documentation, packaging inspection, carrier claims, replacement authorisation, expedited shipping, and prevention.
    • Damaged Item After Usage — distinguishing manufacturing defects from wear or misuse, warranty verification, repair vs. replacement, manufacturer liaison, and proof of purchase.
  • Products
    • Product Information & Specifications — detailed product questions, specs, size charts, compatibility, ingredients, materials, care instructions, and comparisons.
    • Product Availability & Stock — out-of-stock inquiries, restock notifications, backorder timelines, discontinued items, seasonal and regional availability, and pre-orders.
    • Product Recommendations & Alternatives — similar products, cross-sells, alternatives when the preferred item is unavailable, and personalised recommendations.
  • Payments & Invoices
    • Payment Processing Issues — declined transactions, payment-method failures, bank authorisation problems, currency conversion, saved-method errors, and checkout problems.
    • Billing Disputes & Corrections — incorrect or duplicate charges, unauthorised payments, price-matching, promo-code failures, and billing address mismatches.
    • Invoice Management — invoice requests, VAT receipts, corporate billing, payment-term changes, and accounting coordination for business customers.
  • Subscriptions (for subscription businesses only)
    • Subscription Modifications — changing frequency, pausing, upgrading/downgrading, delivery-date changes, and temporary holds.
    • Subscription Billing & Renewals — auto-renewal notifications, failed-payment recovery, price changes, billing-cycle questions, and payment-method updates.
    • Subscription Cancellation — immediate vs. end-of-period cancellation, confirmation, final billing, data retention, and win-back offers.
  • Account
    • Account Access & Security — password resets, lockouts, two-factor setup, suspicious-activity reports, and verification procedures.
    • Profile & Preferences Management — updating personal info, communication preferences, notification settings, privacy controls, and data corrections.
    • Account Closure & Data Requests — account deletion, GDPR compliance, data export, right to be forgotten, reactivation, and final settlements.
  • Other
    • Technical Support & Website Issues — website bugs, app crashes, search issues, page errors, browser compatibility, and accessibility.
    • General Inquiries & Feedback — business hours, contact info, feedback and suggestions, and complaint escalation.
    • Legal & Compliance Matters — terms of service, privacy policy, regulatory compliance, age verification, and legal document requests.
Some scenarios overlap — a damage complaint may end in a return, for example. Because protocols can’t reference each other, include the shared steps directly in each protocol that needs them.