Chatbots and Voicebots in a CDP Stack: Orchestration, Not Just Install

A retailer installs a chat agent on the site. It answers questions about returns, tracks orders when given a number, and resolves a good share of tickets without a person. The vendor’s numbers are real. Klaviyo’s September 2026 release cites a customer whose Customer Agent resolves 86% of queries without a person.

Then a customer who has bought eleven times asks the bot about their delivery and is asked for their email, their order number, and whether they are an existing customer. The bot works. It just doesn’t know who it is talking to, because nobody connected it to the place that does.

In a customer data stack, a chatbot or voicebot is a conversational channel, like email or push. It has the same three needs: who the customer is, what it’s allowed to do with them, and what happened before. Installing it is a week. Connecting it is the project.

Fig 1 · Three things in, three out · What a bot reads from the profile and what it writes back

Three things that have to flow in

Identity. The bot receives a session. To act on a customer, the session has to resolve to a profile: a logged-in user ID, an email the customer confirms, a phone number on a voice call. That is the same identity resolution problem the rest of the stack has, with a new key (the chat session, the caller ID) that needs a rule. Without it, every conversation starts from zero, which is what the eleven-time customer experienced.

Consent and purpose. A bot that answers a delivery question is doing service. A bot that suggests the matching jacket is doing marketing, and it needs the marketing purpose on the profile. A bot that remembers the conversation for next time is storing personal data, with a retention period. Each is a separate purpose, and the consent model has to cover the new channel before it is live, not after the DPO asks.

History. Orders, tickets, the last campaign received, the product viewed twice this week. The bot that can read the profile answers “where is my order” without asking for a number and knows not to offer a discount to someone with an open complaint. The bot that can’t is a FAQ page with a typing indicator.

Three things that have to flow out

The conversation as events. What was asked, what was resolved, what was escalated, on the profile, named like every other event. “Asked about returns” is a churn signal. “Asked whether a size is back in stock” is a wishlist event nobody had to build a form for. A bot that doesn’t write back to the profile throws away the highest-intent data the stack collects.

The handoff. When the bot escalates to a person, the person needs the profile and the transcript, together, immediately. The failure is the customer repeating everything to the agent who took over.

The suppression signal. A customer mid-complaint in chat shouldn’t receive the promotional push that was scheduled for 15:00. The bot’s “open conversation” state is a suppression condition for every other channel, which only works if it lives on the profile the other channels read.

Where orchestration comes in

Once the bot reads and writes the profile, it becomes a step in journeys rather than a separate tool. The post-purchase flow can route a “how is it going” message to chat for customers who used chat before. The win-back for a customer whose last contact was a complaint can start with a service check rather than an offer. The abandoned-cart journey can answer the question the customer asked the bot about shipping, in the email.

That is the difference between a chatbot and a channel. It is the same orchestration rule as everywhere else: one journey, the profile deciding the next step, and a new channel that the profile can choose.

The voice case

Voice adds two things. The identifier is a phone number, which is shared more often than an email and needs a stricter merge rule. And the transcript is generated by speech recognition, so the events written back carry a confidence level the email channel never had. Treat a voice-derived event as a signal to confirm, not a fact to act on, until the customer does something that confirms it.

What to build first

Not the bot. The row in the tracking plan (which events the bot sends and receives, named), the identity rule (how a session becomes a profile), the purpose (what the bot may do with what it knows), and the suppression condition (open conversation blocks promotional sends). Four paragraphs, a week, before the widget goes on the site.

Then the bot, connected, on service questions only, for a month. Then marketing, once the profile shows the bot is reading the right person.

The takeaway

A chatbot is a channel. It needs identity in, consent in, history in, and events, handoffs, and suppression signals out. The vendor’s resolution rates are earned on the service side and they are real. The value on the marketing side comes entirely from the connection to the profile, which is the part no vendor installs for you.

Read next

• Identity resolution: deterministic, probabilistic, and where each breaks. How a chat session becomes a profile.

• Consent management and preference centers: what good looks like. The purposes a bot needs before it markets.

• Journey orchestration across channels. The bot as a step the profile can choose.