AI Agent Customer Journeys: Set Authority by Stage

An AI agent can answer a product question in seconds and still damage the customer journey one step later. The problem is usually not the wording of the reply. It is authority: the agent was allowed to promise, change, book, cancel, or hand off without a precise rule for that stage of the journey.

The safer design is not “AI on” versus “AI off.” Give the agent a different level of authority at each customer stage. Let it answer where the evidence is stable, recommend where the choice is reversible, prepare where a person should confirm, and execute only where identity, policy, and recovery are reliable.

That staged model is becoming relevant quickly. The current WhatsApp leadership sessions describe AI-enabled journeys across discovery, merchant support, communities, upgrade offers, and rebooking notifications. Meta also says its Business Agent can answer questions, recommend products, book appointments, qualify leads, allow a team member to step in, and close sales. Those are very different kinds of authority, even when they happen in one conversation.

A customer journey is a chain of promises

A channel map shows where a message arrived. A journey map should show what the business has promised to do next. That distinction matters because customers do not experience your internal systems. They experience whether the next action is correct, timely, and consistent with the previous conversation.

Start with four plain-language stages:

• Discover: the customer is learning what exists, whether it fits, and what it costs.
• Decide: the customer is comparing options, sharing requirements, or becoming a qualified lead.
• Commit: the customer is booking, ordering, paying, accepting terms, or changing an existing commitment.
• Recover: the customer needs a correction, exception, cancellation, refund, rebooking, or human judgment.

Then write the promise for each stage. “We will explain the published return policy” is not the same promise as “we will authorize a refund.” “We will collect appointment preferences” is not the same as “we will reserve a scarce slot.” The conversational surface can look equally simple while the operational risk is completely different.

This promise-first view also prevents channel bias. A WhatsApp message, an Instagram reply, a web chat, and a voice call may all belong to the same stage. In a unified DripTell inbox, the useful unit is the customer and the active promise—not the tab where the latest message appeared.

Use four authority levels

Assign one authority level to every journey stage and use case. Do not grant the highest level merely because the agent handled the opening question well.

Level 1 — Answer. The agent retrieves approved information and explains it. It may state store hours, product specifications, delivery regions, or the status already recorded in a trusted system. It cannot create a commitment or alter a record. This is the right starting point when the knowledge source is controlled and the cost of a wrong answer is limited.

Level 2 — Recommend. The agent compares options, asks qualifying questions, and suggests a next step. Recommendations must expose important conditions and avoid inventing availability, discounts, or guarantees. The customer can reject the suggestion without needing an operational reversal.

Level 3 — Prepare. The agent gathers the necessary fields, checks policy, and builds a proposed action. A person or the customer confirms before execution. Examples include preparing an appointment request, drafting an order change, or assembling a refund case with evidence. Preparation reduces work without hiding judgment.

Level 4 — Execute. The agent performs the action in a connected system. It may book an available appointment, update a permitted CRM field, or send an approved follow-up. Execution belongs only where authentication, permissions, idempotency, logging, and recovery are proven.

Meta’s Business Agent announcement explicitly combines connected actions with enterprise controls, guardrails, and measurement. The important design lesson is that capability does not automatically equal permission. The business still defines which action is appropriate at which stage.

Write an action contract for every stage

Turn each level into an action contract that operators, developers, and reviewers can inspect. A useful contract answers seven questions:

1. Entry: What verified signal places the customer in this stage?
2. Evidence: Which sources may the agent use, and how fresh must they be?
3. Permission: What may the agent read, propose, write, or send?
4. Confirmation: What must the customer or a teammate explicitly approve?
5. Completion: Which system event proves the promised action happened?
6. Exit: When must the agent stop, transfer ownership, or ask for missing context?
7. Recovery: Who can reverse or correct the action, and what record do they need?

For a fitting appointment, the contract might let the agent answer service questions, recommend a duration, and prepare a booking with the customer’s preferred time. It may execute only after the scheduling system confirms availability and the customer confirms the selected slot. If the calendar write fails, the agent must not claim success; it should preserve the request and transfer it with the failure reason.

This is where broad instructions such as “be helpful” become operational rules. OpenAI’s practical guide to building agents recommends layered guardrails and human intervention when failure thresholds are exceeded or actions are high risk. An action contract makes those intervention points specific to the customer journey rather than leaving them as abstract safety language.

Keep context attached to the customer

Stage-based authority fails if context disappears between channels or owners. The agent needs the current customer goal, what has already been verified, what was promised, which action was attempted, and who owns the next step. It does not need every historical message in every decision.

Maintain a compact journey state with fields such as current stage, intent, verified identity level, consent state, chosen option, open commitment, last completed action, failure reason, and next owner. Store durable business facts in the system of record rather than relying on a generated summary alone.

In DripTell CRM, source, lead stage, custom fields, ownership, and follow-up can stay connected to the conversation. That continuity lets an agent qualify a lead without forcing the salesperson to rediscover the original campaign, requirement, or objection. It also lets a human see whether the agent only recommended an action or actually completed it.

Use least privilege for tools. An agent answering availability may need read access to inventory but no ability to change price. An agent preparing a refund may need the order and policy but no payment permission. When a person takes over, transfer the structured state, the relevant transcript excerpt, the proposed next action, and the reason for escalation. “Customer needs help” is not a useful handoff.

Test stage changes before adding autonomy

Treat every move to a higher authority level as a product release. First collect examples from the real stage: straightforward requests, missing details, ambiguous intent, conflicting records, policy exceptions, repeated messages, and tool failures. Then test both the conversation and the downstream action.

Measure stage-specific outcomes. For Answer, track supported-answer rate, correction rate, and unresolved intent. For Recommend, track whether the recommendation was eligible, accepted, and later reversed. For Prepare, track field completeness and confirmation rate. For Execute, track successful writes, duplicate prevention, false success claims, reversals, and time to recovery. Across all levels, monitor customer opt-outs, human takeover reasons, and complaints.

Promote only one stage or action at a time. A practical sequence is to observe in shadow mode, draft without sending, prepare with approval, execute for a narrow low-risk cohort, and then expand. Define rollback before launch. If the action system is unavailable, the safe fallback may be to keep the conversation open and assign it—not to improvise.

The examples on WhatsApp’s sessions page are useful signals, but reported brand outcomes are not a guarantee for another business. Your evidence is the performance of your own action contract with your own customers, systems, policies, and failure modes.

Put the model to work in DripTell

Choose one high-intent journey rather than automating the whole service operation. A good candidate has a clear customer promise, repeatable inputs, a visible completion event, and a known human owner for exceptions. Appointment qualification, product-fit discovery, quote preparation, or routine order-status follow-up can be easier starting points than refunds or account closure.

Map the journey in six columns: stage, customer promise, authority level, allowed evidence, completion event, and next owner. Connect the conversation to the right contact and lead record. Route exceptions into the Team Inbox, and keep the stage and next action visible in CRM. Only then add the AI behavior that answers, recommends, prepares, or executes within that contract.

The result is not an agent that tries to do everything. It is a customer journey in which every automated step has an explicit promise, a bounded authority level, a completion signal, and a recoverable handoff. That is how AI becomes useful to the business without making the customer carry the operational risk.

Next step: bring one real customer journey to DripTell and define its four authority levels before connecting the agent to a consequential action.