Questions this introduction answers
- We already know a lot about our customers. Why do our messages not show it?
- What does AI actually change about personalization, in one paragraph?
- Which chapters should I read first, given my job?
- How do I hand this handbook to my own AI and get something useful back?
The short answer
Most companies know far more about each customer than they ever say to that customer. The gap is not laziness. It is the old cost of understanding: going deep on one person took a skilled human's hours, so depth was rationed to a few accounts and everyone else got a template. AI is the first technology that can do deep and wide at once. The winners will not have the cleverest prompts. They will build a memory holding an accurate model of each customer, a decision layer that chooses the right next action for one person (including doing nothing), and governance that runs inside the system rather than beside it. This handbook explains how to build those, how to prove they worked, and where the honest limits are. Use the reading paths below rather than reading front to back.
Tuesday, 9:00 a.m.
Larkspur Systems (a fictional company, a composite of many real ones) sells field-service and fleet software. At nine on a Tuesday its quarterly newsletter goes out to 250,000 contacts. The first line reads "Hi {first_name}". For a few thousand contacts the field is empty, so the fallback fires and they get "Hi there".
On that list, one customer's renewal is thirty days out, and the account has not logged in to the reporting module since spring. Another customer's operations director opened three support tickets this week about route sync failing overnight; she is, reasonably, angry. A third account just hired a new head of operations, whose name the CRM picked up from a signature line in a support thread. A fourth has doubled its fleet and is quietly outgrowing its plan.
Larkspur knows all of this. The renewal date is in the CRM, the tickets in the support desk, the usage drop in product telemetry, the new hire in an email thread.
And every one of those people receives the same four paragraphs about the spring product release.
You have sent this email. So have I. Nobody at Larkspur is careless, and the newsletter is well written. The problem is not that the company does not know. It is that knowing and saying have never been connected at the scale of a customer list.
Figure 0.1. Larkspur knows each customer's situation, and every one of them still gets the same email.
Most companies do not have a data problem
Here is the sentence this whole handbook turns on. Most companies do not have a data problem. They have a depth problem.
When personalization disappoints, the instinct is to blame the data. Some of that blame is earned, and Part III is about fixing it. But look again at Larkspur. The facts that matter most to each of those four people already exist. What is missing is the ability to read them for each person, work out what they mean for that person this month, and decide what to say or do about it. That is depth, and depth used to require a person.
Shallow personalization is not worthless, and I want to be precise about that. In randomized field experiments, adding the recipient's name to an email subject line raised open rates from 9.05% to 10.80% and reduced unsubscribes [1]. The merge field earns its keep. But notice what it cannot do. It cannot tell the angry operations director that the sync problem is known and fixed. It cannot tell the renewing account what it stopped using and why that matters. The first name was never the problem. It was the ceiling.
Customers notice the ceiling. In Salesforce's 2023 survey of 14,300 consumers and business buyers across 25 countries, 61% said most companies treat them as a number, and 73% of business buyers said most sales interactions feel transactional [2]. These are survey responses, not behavior. They are still a fair description of what "Hi {first_name}" feels like from the other side.
Why depth was always rationed
For most of the history of commerce, attention had to be rationed. To write something that genuinely fits one customer, someone had to understand that customer: their situation, their language, what they were trying to get done. That took hours, and skilled hours are finite. The account manager who knows forty clients well cannot know four thousand. The marketer who reaches four thousand cannot know any of them.
That is the frame this handbook is built on (Chapter 4 develops it). Picture a grid: depth of understanding on one axis, scale on the other. Human one-to-one service (account managers, advisors, concierge desks) is deep and few. First-era machine personalization (merge fields, segments, recommenders, propensity scores) is wide and shallow. The corner that stayed empty was deep and wide, because the arithmetic did not allow it. AI changes the arithmetic. Reading a support thread, a call transcript, and years of usage history, then reasoning about what they mean for one account, is now machine work, across an entire customer base.
The idea itself is not new, and I should say so. Don Peppers and Martha Rogers argued in 1993 that companies should compete on share of customer, building relationships "one customer at a time" [3]. This handbook's title owes them an acknowledgment. What they could describe but not deliver was the cost of understanding each person. That cost is what has fallen.
What this handbook is, and is not
It is a practitioner's guide, written by someone who builds these systems. I built and run a governed personalization engine that turns one record of a person, an account, and a campaign into a web page, an email sequence, and a seller brief, with code checks, safe fallbacks, and delivery recovery wrapped around the model. I also built a self-hosted memory system that keeps that record in the customer's own database and tidies it while idle, proposing its own corrections before an operator lets it write them. The memory architecture behind both is described in a public paper [4]. So the handbook shows the mechanism, the cost math as ranges, and the failures. It is not an argument for maximal personalization. More detail about a person often makes a message worse, and one correct fact that changes what should be said is worth more than a hundred that only decorate it. The standard throughout is simple: be specific and true, or be honestly general. It is not a vendor catalog, not a promise of revenue, and not a manual for pressuring people. Any system precise enough to serve a person is precise enough to pressure them, which is why governance gets an entire Part rather than a closing paragraph.
Who this is for, and where to start
Seven readers, one text. Every chapter opens with a short answer a leader can stop at, then goes deeper for the people who build.
| If you are | Your Monday | Start with |
|---|---|---|
| CEO | "We have ten years of customer data. Why doesn't it make us money?" | Ch 1, 4, 6, 14 (short answer), 21, Closing |
| CMO | The board wants "our AI personalization story"; the team runs merge fields | Ch 1, 2, 4, 6, 15, 16, 21; Playbooks M1 to M3 |
| CRO | AI SDR tools produce plausible spam and reply rates fall | Ch 1, 4, 10, 15; Playbooks S1, S2, and One Customer, One Conversation |
| Product leader | An experience should adapt, and it is unclear whether rules, a model, or an LLM should drive it | Ch 1, 3, 4, 14, 16, 17, 21; Playbooks Product and Software Companies |
| CTO or architect | Seven teams, seven personalization stacks, no shared memory | Ch 3, 9 to 13, 16, 18, 20, 22 |
| AI builder or GTM engineer | You can wire agents in a weekend but were never trained in personalization | The companion repo, then Ch 8 to 17, 20, 22 |
| Software founder or customer success leader | Most trials never convert, and the health score is green on accounts that leave | Ch 1, 6, 10, 14, 21; Playbooks Software Companies and Customer Success |
The handbook has two layers. Foundations (Parts I to VII, twenty-two chapters between this introduction and the closing) holds the durable ideas: the case, where to start, customer data, memory, decisions, trust, and proof. Playbooks (Part VIII, eleven playbooks) applies them by function (marketing, sales, support, customer success, product, research, and the coordination across them) and, in one case, by business model (software companies). That layer changes as channels and platforms change.
Figure 0.2. Seven parts of durable foundations, applied by function in playbooks that change with the channels.
How to use this with your AI
This handbook has two readers: you, and the AI you will ask to help apply it. Every chapter ends with a block called For your AI: structured YAML holding the chapter's concepts, its decision rules, the questions an assistant should ask about your company, and its named patterns and anti-patterns. Concept names stay stable across chapters, so an assistant can connect them. Every chapter is also published as clean Markdown, and the site offers an llms.txt index and a single full-text file, so "give the whole handbook to your AI" is one link.
Two skills in the companion repo turn reading into a plan. Assess interviews you about your company and scores you on six maturity dimensions, with the evidence and the gaps. Plan takes that assessment and the handbook and drafts your first three decisions to personalize, a starter memory schema, governance rules, a measurement plan, and a 90-day build sequence. It is built to make gaps visible, not to flatter.
The company you will watch change
Larkspur will reappear in most chapters. It has about 40,000 customer accounts, 250,000 contacts, ten years of CRM history, a warehouse, product telemetry, events, a support desk, and a small direct-mail program. It starts where most companies start: five segments, merge fields, a quarterly newsletter, and an AI SDR pilot that is making reply rates worse, not better.
Each chapter moves it one step: choosing its first decisions, fixing identity, building memory, adding a decision layer, governing, measuring, deploying. The closing chapter shows Larkspur a year later.
The goal is not a better newsletter. It is that the renewing customer, the angry operations director, the new head of operations, and the growing fleet each hear something true and useful about their own situation, or hear nothing at all when nothing is the right answer.
Personalization was never about the first name. It is about knowing one person well enough to decide what they need, and doing that for everyone.
References
- Sahni, N. S., Wheeler, S. C., and Chintagunta, P. (2018). "Personalization in Email Marketing: The Role of Noninformative Advertising Content." Marketing Science 37(2). https://pubsonline.informs.org/doi/abs/10.1287/mksc.2017.1066
- Salesforce (2023). State of the Connected Customer, 6th edition. Double-blind survey of 14,300 consumers and business buyers in 25 countries, fielded May 3 to July 14, 2023. Report PDF (hosted copy): https://event.hbrturkiye.com/storage/uploads/state-of-the-connected-customer-655b114557dfa.pdf
- Peppers, D., and Rogers, M. (1993). The One to One Future: Building Relationships One Customer at a Time. Currency/Doubleday.
- Taheri, H. (2026). "Governed Memory: A Production Architecture for Multi-Agent Workflows." arXiv:2603.17787. https://arxiv.org/abs/2603.17787
This chapter is a working draft. If something is wrong or missing, tell me on LinkedIn.
Get chapters by email as they are revised