One Customer, One Conversation

Questions this playbook answers

• Every team's program performs well on its own dashboard. Why do our best customers say we feel like five companies?
• Who decides what one person hears from us this week, when four teams and six agents all have something to say?
• How many messages is too many, and should that number be the same for everyone?
• What has to be shared, beyond customer data, so that two teams never tell one person two different things?
• How do we prove that coordination is worth the messages it stops?

The moment

Larkspur Systems is a fictional composite company used throughout this handbook: field-service and fleet software, about 40,000 accounts and 250,000 contacts. Every person and customer below is fictional.

Grace Adeyemi joined Harlow Fleet Services as vice president of operations three weeks ago. Harlow is one of Larkspur's larger customers: 400 technician seats, a renewal in the spring, and a route-sync problem last summer that Priya, the account manager, spent a month repairing. Dana, Harlow's fleet operations lead, now reports to Grace.

Here is what Larkspur said to Grace in her first nine days.

An enrichment feed spotted her job change and created a new lead record, because nobody had told it Harlow was a customer. Marketing's new-hire trigger enrolled her in a prospect nurture that opened with "See why fleets like yours are switching to Larkspur." The outbound agent, reading the same lead record, offered her a free fleet assessment. Customer success invited her to administrator training. The support copilot answered her first ticket, about a sync delay, by saying the fix would ship "in the next release, at the end of the month." Two days later an in-product banner told her the fix was already live. The events team invited her to a customer dinner and, separately, to a webinar for prospects. And a promotional email offered 15% off an add-on "for new teams," the same week the renewal agent sent Priya a draft proposal with a price increase.

Fourteen messages, six senders, two direct contradictions. Every one of them was accurate by its sender's lights. Grace forwarded three of them to Priya with one line: "Which of these is Larkspur?"

Every other playbook in Part VIII personalizes one function well. This one makes sure the functions add up to one company. The seams it closes are sharpest in software businesses, where product, sales, and customer success each hold a copy of the same account (Playbooks SW and CS).

The decision

The decision in this playbook is not what to say. The other playbooks decide that. It is arbitration: given everything every team and every agent wants to send to this person in the coming window, which actions go, in what order, merged how, and which wait or die.

Here is the sentence this playbook turns on: the customer does not experience your org chart; she experiences the sum of it, and somebody has to own the sum.

Chapter 14 introduced the idea as one line of its checklist (a per-person contact budget enforced at one arbitration point). This playbook is the operating detail. The options for each pending action are:

Arbitration needs a precedence order that everyone agreed to before the argument, not during it. The one I recommend, from strongest to weakest:

1. Hard constraints. Consent, opt-outs per purpose and channel, legal holds, and promises the company made (Chapter 18's customer-level governance). These remove actions; they are never weighed.
2. Service before selling. An open issue for this person or account defers every promotional and expansion action. Dana's upsell in Chapter 14 dies here.
3. Operational necessity. Security notices, billing, contract and renewal paperwork, and service changes the customer needs to run their business. These are exempt from the budget, but they are not exempt from the record, and they still count as contact when the next promotional decision is made.
4. The relationship owner. Where a named human owns the account, that person can merge, reroute, or veto anything an agent or a program proposed.
5. Value against attention. What remains competes on expected incremental value (Chapter 14's uplift, not propensity) net of the attention it spends.

The fifth rule is where the budget lives. Every person will read only so many of your messages with goodwill, and every team spends from that balance whether it can see it or not.

The strongest recent evidence on what that balance costs comes from a field experiment by Baek, Chen, Ma and Mitrofanov. A major North American online retailer randomly assigned 603,153 customers, for one week in October 2024, either to its usual daily coupon emails or to one email every two days [1]. Fewer emails cut unsubscriptions by 59% and cost 5 to 8% of short-term revenue and purchase rate. Separately, in a year of history for about 200,000 customers, unsubscribing reduced a customer's monthly spending by 36%. When the authors fed both estimates into a lifetime-value model, personalizing email frequency raised average customer lifetime value by 6.8% under a policy that maximized immediate revenue and 8.3% under a full lifetime-value policy, both against the daily baseline [1]. LinkedIn reached the same conclusion from the other direction when it removed four of every ten emails and reported member complaints cut in half (Chapter 14) [2].

Two lessons carry into B2B. The right frequency is per person: in Baek's data, cutting frequency reduced churn most among customers who opened many emails but used few coupons, and cost the most revenue among heavy buyers who rarely opened. And the cost of contact arrives later than the benefit, which is why every team's weekly metric asks for one more send. Gartner's 2025 survey of 632 B2B buyers found 73% actively avoid suppliers that send irrelevant outreach [3]. Avoidance is not an unsubscribe. It is quieter, and it is what Grace was about to do.

The limits of that evidence matter. Baek et al. is a working paper, from one retailer, testing coupon email over a single week, with a lifetime-value gain that comes from a model rather than observed years. A fleet-software buyer is not a coupon shopper. What transfers is the shape of the tradeoff (short-term lift, deferred churn, heterogeneous people), not the percentages. Anyone quoting you an optimal number of B2B emails per month is quoting an average of people who are not your customer.

What you need to know

Contradictions have two sources, and teams usually fix only the first. Different facts: support knows the fix is live, marketing does not. Different rules: the promotion's discount policy lives in one team's prompt and the renewal pricing policy in another's, the fourteen-configurations problem from my own work [4]. When I wrote up the shared memory layer I built for multi-agent workflows, these were the first two structural problems on the list: memory silos across agent workflows, and governance fragmented across teams and tools [8]. One conversation requires four shared things, and each is a different kind of object.

1. One memory of the person and the account (what we know). The same record every surface reads (Chapter 10), with identity resolved first (Chapter 9). Grace became a "lead" because a job change created a new record instead of a new role on a known person at a known customer. The first contradiction was an identity failure, and no amount of copy review would have caught it. Freshness matters as much as unity: a role change, a closed ticket, and a shipped fix are exactly the facts that go stale in one system while another has moved on (Chapter 11).

2. A contact ledger (what we said). Every customer-facing touch, from every team, tool, agent, and human inbox, written to the person's record: when, channel, sender, topic, and, most importantly, the claims made. "Fix ships end of month" is a claim. "15% off for new teams" is a claim. When the next agent drafts, it reads what the company has already told this person, so it can agree with it, correct it deliberately, or stay silent. Most stacks log sends per tool; almost none log claims per person. Stamp the sender on the send path, never take it from the agent: in the memory system I built, the server stamps each automated write with its process and run, where no model can forge it. Zendesk's 2026 trends survey (fielded June 2025, over 11,000 respondents) found 81% of consumers want agents to continue the conversation without backtracking and 74% are frustrated when they must repeat information [5]. The ledger is how a copilot knows what the last conversation was.

3. Open commitments and constraints (what we promised, what we may not do). Promises, holds, quiet periods, preferred channel, and the relationship owner are typed fields, not notes (Chapter 18). By the Boundary Rule (Chapter 10), "no outreach before March 1" is a WHERE clause, so it is a property. The gist of last Tuesday's call is a paragraph, so it is a memory. 4. One set of rules (what anyone may say). Pricing authority, offer eligibility, roadmap language, and brand voice, owned once and served by reference to every agent (Chapter 18). "By reference" means retrieved at the moment of action, not pasted into fourteen prompts: in the systems I build, one retrieval returns the person's record together with the rules for this action, and each campaign's guideline is addressed by a stable identifier so two similarly named programs cannot borrow each other's offer. If the promotion and the renewal read the same pricing policy, the 15% offer either is not generated for a customer mid-renewal or is generated knowingly.

In B2B there is a fifth consideration: the account is also a budget. Grace, Dana, and four other Harlow people forward each other Larkspur's email. Six contacts each at a sensible personal frequency can still add up to a vendor that will not stop talking. Keep a per-person budget and an account-level ceiling, and let the account view show every pending action for every contact.

Each fact in the shared memory also carries its allowed surfaces next to its provenance [6]. Unifying memory does not mean every team may use everything. What Grace told support about a staffing problem may shape the account manager's tone and must never appear in a marketing email (Chapter 19). The boundary I enforce hardest is rep-internal is not customer-facing. A seller brief may hold hypotheses and competitive context that must never reach a buyer, so in the engine I built an explicit serializer decides what leaves the system, and seller-only analysis stays behind even when someone adds a new internal field. A prompt instruction to "keep this internal" is not a boundary; serialization is.

The action

Coordination is an architecture change more than a policy memo. Four moves make it real.

Figure P9.1. Propose, do not send: one coordinator applies an agreed precedence, and the send path checks again before anything reaches the customer.

Propose, do not send. Every program, tool, and agent submits a proposed action (who, what, why, which claims, urgency, expiry) to a shared queue instead of sending directly. That includes every other playbook's output: the inbound reply (M1), account and event touches (M2), the mailer (M3), prospecting and expansion (S1, S2), in-product messages (PR), and proactive support (SP). Replies to a customer who wrote in are the exception on timing, not on record: they go immediately and write to the ledger at once.

Arbitrate on a schedule, re-check at send time. A coordinator runs daily over the next window for every person with pending proposals: apply the precedence order, spend the budget, merge where three teams want the same person, and emit a decision with a reason for every proposal, including the ones it killed. Planned outreach is asynchronous by nature, so this is a batch job, not a real-time system (Chapter 17). But state changes between decision and delivery, so the send path re-checks hard constraints and takes a short per-person lock, so two messages approved in the same minute cannot both go out. A 6 a.m. decision is not a license to send at 4 p.m. after a noon ticket. The rules themselves are small:

arbitration:
  window: 7d
  budget:
    person_promotional_max: 2          # per window; set per segment, then learn per person
    account_promotional_max: 6
  exempt_from_budget: [service_reply, security, billing, contract]
  precedence:
    - suppress_if: [opt_out_for_purpose, legal_hold, active_promise_hold]
    - defer_if: [open_ticket_sev1_or_sev2, onboarding_first_14d]
    - owner_review_if: [account_tier_strategic, claim_conflicts_ledger]
    - rank_by: expected_uplift_minus_attention_cost
  merge:
    when: "3+ proposals from different teams in one window"
    deliver_as: relationship_owner
  always_log: [decision, reason, proposals_considered, rule_version]

Compile every surface from one context. Once an action wins, the channel that delivers it (email, in-product banner, notification, rep talking point, printed piece; Chapter 16 covers the experiences) compiles from the same governed context, never from its own copy of the customer (Chapter 15's channel compilers) [6]. The banner and the support reply about the sync fix would then have read the same release status. In the engine I built, research and context are assembled once and compiled into the landing page, the email, the seller brief, and the report. Each surface keeps its own job (the brief analytical, the email short) but none has its own facts, which removes contradiction and duplicated integration work together. When programs overlap, scope each page's identity to its campaign: the same company can sit in two programs, and without that scope one program's page overwrites the other's.

Give the relationship owner the view. Priya should be able to open Harlow and see the next seven days: every pending proposal for every contact, what the coordinator decided, and why. She can merge the training invite, the dinner, and the renewal preview into one note from her, and drop the prospect nurture outright. For strategic accounts, a human merging three messages into one is often the best-performing "agent" in the building.

Agents deserve one rule of their own: an agent should not hold its own send credential. Chapter 18's first control is removing authority, and here it is literal. If every agent can only propose, a new agent added by a new team next quarter joins the conversation instead of starting a second one. The same rule governs memory. In the self-hosted memory system I built, each agent can get its own key scoped to a role and a data slice, and a read-only agent connecting over MCP never sees the write tools. A hosted long-running job gets a credential minted for it alone: three memory tools, expiring within a day, revoked when the job ends. In the multi-agent systems I build, the capability that surprised me most came from specialists writing into shared state rather than reporting to each other: once one agent's finding changes what the next one is allowed to assume, the system stops contradicting itself as a side effect.

For Grace, the coordinated version looks like this. Identity attaches her to Harlow as a new contact. The nurture, the assessment offer, and the prospect webinar are suppressed: prospect programs never reach a customer. The promotion is deferred because Harlow is in the renewal window and the pricing policy says renewal offers come from the owner. The support reply reads release status from the same source as the banner. And Priya sends one message: welcome, what happened with route sync and what was fixed, training for Grace's team, and an invitation to the dinner. Four teams contributed to it. Grace received one.

Figure P9.2. The customer experiences the sum of the org chart: fourteen uncoordinated messages with two contradictions, or one message that four teams contributed to.

What can go wrong

Failure story: The Side Door. Larkspur built its coordinator, wired in marketing automation and the outbound agents, and watched contradictions fall. Six months later the account team at another large customer received a complaint that read exactly like Grace's. The investigation found two senders outside the queue: the events team's registration platform, which sent its own reminders, and an AI sales assistant a regional team had bought on a credit card, sending from reps' own mailboxes. Neither wrote to the ledger. The coordinator's reports looked clean because it could only count what it saw. The fix was organizational as much as technical: a rule that nothing sends to customers without writing to the ledger, enforced where it can be (sending domains, mailbox integrations, vendor contracts), and a metric for the share of customer-facing sends that passed through the coordinator. A contact budget with a side door is a suggestion.

The other risks, in rough order of frequency:

• Over-suppression. A budget tuned only against annoyance will silence what the customer needed. Chapter 14's warning applies: a customer in trouble who hears nothing may conclude nobody noticed. Operational messages stay exempt, and the coordinator's suppression log is reviewed for important messages that died.
• Arbitration by volume. Without an agreed objective, the team that shouts loudest owns the budget. Precedence and value weights are set by leadership and versioned like any other rule (Chapter 18), not renegotiated per campaign.
• One budget for everyone. A flat cap is better than none and worse than a per-person budget learned from each person's own responses. Start with a conservative per-segment cap; do not copy another company's number.
• The race. Two teams' messages approved separately arrive in the same hour because the ledger updates after sending. The send-time lock and re-check exist for this.
• Shared memory as a leak. Unifying memory makes it easier for a sensitive support disclosure to surface in a sales draft. Allowed-surface metadata and grounding checks on every personal claim (Chapters 15 and 20) are what keep one memory from becoming one megaphone.
• Coordination used to press harder. The coordinator sees every touch to one person. The budget exists to spend less attention, not to orchestrate more, and its objective should say so.

How you will know

Measure the sum, not the parts. Five metrics, most of which no single team tracks today:

1. Contact distribution per person and per account, weekly: the median and, more important, the 95th percentile. Averages hide the Graces.
2. Contradiction rate: claims in the ledger that conflict with an earlier claim or with current memory (price, dates, product status), per thousand active accounts, from automated checks plus a monthly human sample.
3. Negative responses per person: unsubscribes, spam reports, channel disengagement, and "please coordinate" complaints, against contact volume.
4. Coverage: the share of customer-facing sends that passed through the coordinator. Below 100% is your Side Door.
5. Repeat asks: support conversations where the customer restates something the company already had. In Salesforce's 2020 survey of about 15,600 consumers and business buyers, 54% agreed "it generally feels like I'm communicating with separate departments, not one company," and 65% said they often have to repeat or re-explain information [7]. The data is six years old and vendor-run; your own repeat-ask rate is the current version.

The outcome that justifies the whole thing is slower: retention and expansion at renewal, and the health of the channels themselves.

Test design. Randomize at the account level, not the person level, because Harlow's contacts talk to each other and a coordinated Grace next to an uncoordinated Dana contaminates both. Hold out a random share of accounts (Larkspur chose 10%, about 4,000 accounts) that keep today's uncoordinated programs, and run the comparison through at least one full renewal cycle. Expect Baek's pattern: the coordinated arm will look worse on short-term sends-driven metrics in the first weeks, because it sends less. Negative responses and contact distribution will separate within weeks; renewal and expansion need quarters. Write down before the test which metric decides it, or the first month's dip will end it (Chapter 21).

Reader Q&A

We have a journey orchestration tool with frequency capping. Is that not this? Partly. Most caps work per channel inside one tool. The gaps are across tools, across teams, from reps' own mailboxes, and from agents, and none of them log claims. Check your tool's cap against the coverage metric before assuming it covers the conversation.

Who owns the budget? Not marketing, sales, or support, since each is a bidder. In most companies it is a revenue or customer operations function with an executive sponsor, and the rules are versioned like any other governance artifact.

Does a support reply count against the budget? No: when the customer wrote to you, answer. It does count as context, and it can defer the promotional message scheduled for tomorrow.

Where do we start? With the ledger and a single account view for relationship owners. Seeing the sum is what persuades teams to share the rest.