Introduction: Hi {first_name}

Why this handbook, and how should I read it?

Working draft, revised September 2026 · 11 min read · Markdown for your AI

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.

Larkspur (fictional) already knows four customers' situations: one account renews in 30 days and has not used the reporting module since spring; an angry operations director opened three tickets this week about route sync failing overnight; a new head of operations was picked up from a support signature; and one account has doubled its fleet and is outgrowing its plan. These facts sit in the CRM, the support desk, product telemetry, and email threads. Yet all four, along with 250,000 contacts, receive the same Tuesday 9:00 a.m. newsletter: "Hi {first_name}" (or "Hi there" when the field is empty) and the same four paragraphs about the spring product release. The gap is not data; knowing and saying were never connected at the scale of a 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 areYour MondayStart 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
CMOThe board wants "our AI personalization story"; the team runs merge fieldsCh 1, 2, 4, 6, 15, 16, 21; Playbooks M1 to M3
CROAI SDR tools produce plausible spam and reply rates fallCh 1, 4, 10, 15; Playbooks S1, S2, and One Customer, One Conversation
Product leaderAn experience should adapt, and it is unclear whether rules, a model, or an LLM should drive itCh 1, 3, 4, 14, 16, 17, 21; Playbooks Product and Software Companies
CTO or architectSeven teams, seven personalization stacks, no shared memoryCh 3, 9 to 13, 16, 18, 20, 22
AI builder or GTM engineerYou can wire agents in a weekend but were never trained in personalizationThe companion repo, then Ch 8 to 17, 20, 22
Software founder or customer success leaderMost trials never convert, and the health score is green on accounts that leaveCh 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.

The handbook has two layers. Foundations, Parts I to VII, hold the durable ideas in twenty-two chapters framed by the Introduction (Chapter 0) and the Closing (Chapter 23): Part I, the case (Chapters 1 to 5); Part II, where to start (Chapter 6); Part III, customer data (Chapters 7 to 9); Part IV, memory (Chapters 10 to 13); Part V, decisions (Chapters 14 to 17); Part VI, trust (Chapters 18 to 20); and Part VII, proof (Chapters 21 and 22). Playbooks, Part VIII, apply those foundations by function and business model in eleven playbooks: marketing (M1 to M3), sales (S1, S2), support (SP), customer success (CS), product (PR), research (RS), one customer, one conversation (P9), and software companies (SW); they change 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

  1. 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
  2. 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
  3. Peppers, D., and Rogers, M. (1993). The One to One Future: Building Relationships One Customer at a Time. Currency/Doubleday.
  4. 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

Prefer LinkedIn? Subscribe to the newsletter there instead.