WhatsApp Policies and Operating Rules Template

Outcome Summary

Define clear business boundaries (refunds, delivery, hours, service scope) your WhatsApp AI Agent can follow consistently.
Reduce back-and-forth by turning “it depends” topics into approved, reusable policy answers.
Make escalation predictable by deciding what the Agent should answer vs when it should create an Inquiry for human handoff.

What Clarivo Actually Does (Truth Block)

✅ Clarivo does

Connect an AI Agent to your WhatsApp Business number to respond to inbound messages.
Learn from what you provide (business description, FAQ, services list, and additional instructions like tone and do/don’t rules).
Capture Leads automatically when intent is detected (when enabled).
Create an Inquiry when it can’t answer confidently, so a human can take over instead of the Agent guessing.
Support multilingual conversations and understand WhatsApp voice notes (with transcription visible in the dashboard).

❌ Clarivo does not

Run outbound broadcast campaigns or mass messaging.
Guarantee appointment booking (it can collect preferred times/details; a human confirms).
Process payments inside the product.
Sync real-time inventory or MLS data.
Replace a full omnichannel inbox (it’s WhatsApp-focused).

The Core Problem

Customers ask policy-heavy questions on WhatsApp (“Can I refund?”, “Do you deliver here?”, “Are you open now?”) and expect instant, consistent answers.
Teams answer differently depending on who is replying, which creates disputes and exceptions you didn’t intend.
Some questions require nuance (edge cases, sensitive issues), but without rules the Agent may either over-escalate or answer too confidently.
“Operating rules” are often scattered across notes, staff memory, and old messages—hard to keep aligned.
Without escalation rules, humans jump in late (after confusion), not early (at the right decision point).

Framework

Step one: List your boundary topics (the ones that create conflict)

Start with the categories customers repeatedly challenge:

Refunds/returns/cancellations
Delivery/pickup/service area
Hours and response expectations
Eligibility and what you will not do
Pricing expectations and quotes
Guarantees, outcomes, and liability language

Step two: Decide the “default answer” and the “exception path”

For each topic, write:

The default rule the Agent should stick to
What counts as an exception
Whether exceptions are allowed at all, or must be handled by a human

Step three: Turn rules into two layers of content

You’ll usually need both:

Customer-facing wording (friendly, short, copy/paste ready)
Agent instruction wording (clear do/don’t boundaries)

Step four: Paste the templates below into your Agent setup

Use these as:

FAQ entries (question → answer), and/or
“Additional instructions” (operating rules the Agent must follow)

Copy/paste templates (edit the brackets)

Template: Business hours + response expectations

Customer reply: “Our hours are [Days] [Opening time]–[Closing time]. If you message outside those hours, we’ll reply as soon as we’re back. If this is urgent, please share [urgent details we need] so we can prioritize.”
Agent instruction: “State hours exactly as provided. Do not promise immediate replies. If urgent language is detected, ask for [urgent details] and create an Inquiry if it affects safety, health, or time-sensitive delivery.”

Template: Refunds / cancellations policy

Customer reply: “Refunds and cancellations depend on [condition]. If you share your [order details / booking details], we’ll confirm what applies to your case.”
Agent instruction: “Never approve exceptions. Ask for [required details]. If the customer disputes, requests a manager, or mentions chargeback/legal action, create an Inquiry.”

Template: Delivery / pickup / service area

Customer reply: “We currently serve [areas]. If you send your [location], I’ll confirm whether we can deliver/visit and what the options are.”
Agent instruction: “Confirm service area from the provided list only. If outside the area, offer alternatives (pickup / nearest supported zone) if allowed. If the customer requests a special trip, escalate.”

Template: What we do / don’t do (scope control)

Customer reply: “We can help with [supported services]. We don’t provide [excluded service]. If you tell me what you’re trying to achieve, I’ll point you to the closest option we offer.”
Agent instruction: “Do not invent services. If request is outside scope, say so clearly and offer supported alternatives. If customer insists or the request is sensitive, create an Inquiry.”

Template: Pricing expectations (avoid ‘made-up quotes’)

Customer reply: “Pricing depends on [drivers]. If you share [details], we’ll estimate the right option and confirm the final price before we proceed.”
Agent instruction: “Use only the pricing info provided in the services list/FAQ. If missing, do not guess—ask for details and create an Inquiry if a precise quote is required.”

Template: Human handoff + inquiry trigger

Customer reply: “I can help with the basics here. For anything that needs a specialist, I’ll pass it to our team and they’ll reply in this chat.”
Agent instruction: “Create an Inquiry when confidence is low, when policy exceptions are requested, or when the message indicates risk (medical, legal, safety, harassment). Keep the conversation calm and collect the minimum details needed for the human.”

Step five: Define your lead capture fields (so policies drive action)

When a customer shows intent, decide what the Agent should capture consistently, such as:

What they want
Where they are (if location matters)
Timing preference
Any constraints that affect eligibility or cost

Step six: Create “edge-case” rules so the Agent doesn’t get trapped

Examples of edge cases to define upfront:

Angry customer demanding an exception
Customer claims a prior promise
Customer asks for something you explicitly don’t offer
Customer sends a voice note with unclear details

Step seven: Test with real conversations and refine

Run a small set of your most common questions:

Confirm the Agent uses your exact boundaries
Confirm it escalates when it should
Tighten language that causes arguments or misinterpretation

Use Cases

Use case: Home services (cleaning, maintenance, onsite visits)

Scenario: A customer asks if you can come “today” and whether there’s a cancellation fee.
Recommended approach: Use the “hours/response expectations” + “refunds/cancellations” templates, then capture location and timing as lead fields. Escalate if they demand an exception.
Common mistake: Letting the Agent imply availability or confirm fees without your written rule (leads to disputes).

Use case: Clinics (inquiry intake + boundaries)

Scenario: A customer asks a medical question and wants advice over WhatsApp.
Recommended approach: Use scope control language (“we can help with scheduling/info, not diagnosis”), collect the minimum intake details, and create an Inquiry for a human.
Common mistake: Over-explaining or drifting into guidance that should be handled by a clinician (risk and mistrust).

Use case: Restaurants (reservations requests + delivery questions)

Scenario: A customer asks if you deliver to their neighborhood and wants a table “later”.
Recommended approach: Use the delivery/service area template, then collect preferred time and party details for human confirmation.
Common mistake: Treating a reservation as confirmed instead of “request received” (creates no-shows and frustration).

Decision Checklist

Are your most-disputed topics written as explicit rules (not just “we’ll see”)?
For each policy, did you define the exception path (allowed vs escalate vs not allowed)?
Can the Agent answer with information you actually provided (FAQ/services/instructions), without guessing?
Do you have clear Inquiry triggers for sensitive, risky, or ambiguous messages?
Are your customer replies short enough for WhatsApp, with optional detail only when needed?
Do your policies match what your team will actually enforce (so humans don’t undermine the Agent)?
Did you define what details to capture as a Lead before escalation (so humans don’t start from zero)?

Constraints

Policies can be business-critical: if you operate in a regulated space, have a qualified person review customer-facing wording.
WhatsApp conversations are fast-moving; overly long policies often get ignored or misunderstood.
If your pricing/rules change frequently, you need an owner and a simple update process to keep the Agent aligned.
Clarivo is WhatsApp-focused and inbound-oriented; operating rules should assume the customer messages first.
Some outcomes (like confirmed bookings or exceptions) still require human confirmation.

Common Mistakes

Writing policies like internal memos: customers feel dismissed, and the conversation escalates instead of resolving.
Not defining exception handling: the Agent either blocks legitimate edge cases or creates “special treatment” chaos.
Letting the Agent answer without source content: missing details push it toward vague responses or unnecessary escalation.
Using absolute promises (“guaranteed”, “always”): you create disputes when reality differs.
Forgetting to define lead details before escalation: humans take over without context and customers have to repeat themselves.

FAQ

Should these templates go in FAQ or operating instructions? If it’s a repeat question customers ask, put it in FAQ. If it’s a behind-the-scenes rule the Agent must follow (especially escalation triggers and do/don’t boundaries), put it in additional instructions.

How do I stop the Agent from making up answers about pricing or exceptions? Only provide the pricing/rules you’re willing to publish, instruct the Agent to not guess when details are missing, and define when it should create an Inquiry.

What if my policy depends on context (photos, condition, distance)? Make the default response a short “depends on” with a clear request for the inputs you need, then escalate when a human decision is required.

Can the Agent handle voice notes about policy questions? Yes—if you provide the policy content, the Agent can use it to respond after transcribing the voice note. If the voice note is ambiguous or sensitive, define an Inquiry trigger.

Do I need to publish every rule publicly? No. Keep customer-facing language simple and fair, and keep internal decision rules in your operating instructions (especially for escalation and exceptions).