# Playbook M1. Inbound and the Website

*The question: They came to us. What should they see and receive next?*

> **Questions this playbook answers**
> - A demo request just arrived. How fast do we need to answer, and with what?
> - Should our website change for each visitor, and how much can it know about someone who has not told us who they are?
> - What can AI generate for an inbound lead without inventing things about them?
> - Who should get a person, who should get an automated reply, and who should get nothing new?
> - How do we prove any of it worked with B2B volumes?

## 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.*

Tuesday, 4:52 p.m. Rosa Alvarez, operations manager at Cardinal Mechanical (also fictional), a heating and plumbing contractor, has spent eleven minutes on Larkspur's website. She read the route-optimization page twice, opened a case study about a contractor with two branches, and filled in the demo form. In the free-text box, the one most forms make optional, she wrote: "38 techs across two branches. Our dispatcher quit last month and I am doing it myself from a spreadsheet."

Here is what old Larkspur did with that. An auto-reply thanked "Rosa" for her interest. The lead entered a round-robin queue. On Thursday a sales development rep called with the standard discovery script and asked how many technicians she had. On Friday she was enrolled in the same five-email nurture track as everyone else who had ever downloaded a guide. Nobody read the sentence about the dispatcher.

That is not an unusual failure; it is the median one. In an audit of 2,241 US firms published in HBR in 2011, Oldroyd, McElheran and Elkington sent each a web lead: 37% replied within an hour, 24% took more than a day, and 23% never replied at all. The average response among firms that replied within 30 days was 42 hours [1].

Here is the new Larkspur, the "fast win" chosen in Chapter 6. Within minutes of Rosa's submission, an agent checks whether Cardinal is already known, researches the account (or reads research another lead from Cardinal already paid for), and drafts two things: a brief for the rep and a first reply. The rep reads both, edits one sentence, and sends before 5:30. The reply answers what she wrote: it offers a 20-minute session on running dispatch for two branches without a dedicated dispatcher, links a page built for that situation, and asks one question about how jobs arrive today. Nothing in it claims to know anything she did not tell Larkspur or that is not public.

## The decision

This is the one place in personalization where the customer went first. Rosa told Larkspur who she is, what she has, and what hurts, in her own words. Here is the sentence this playbook turns on: **an inbound lead is not a prospect to be researched; it is a request to be answered, and the answer is personalized first by what the person told you.**

Most inbound programs decide the wrong things. They decide how to score the lead and which sequence to enroll it in. The decisions that matter, for each inbound moment, are these:

| Decision | Options (always including nothing) |
|---|---|
| Who responds | A rep, a specialist, customer success (if they are already a customer), support (if the "lead" is a problem), self-serve, no one new |
| How fast | Now, within the hour, next business morning (a considered answer beats a fast wrong one) |
| With what | An answer to their stated need, a question, a booked time, a resource, nothing further |
| What the site shows next | The default page, a variant chosen by context, a variant chosen by account, a page built for this lead |
| What to ask | One question that changes the next decision, or nothing |

"Nothing new" is a real answer more often than inbound teams admit. The form fill from a current customer with an open escalation belongs to their account manager, not to a sales sequence (Chapter 14's upsell that should not go out). The student, the job seeker, the competitor and the vendor pitching you need a polite routing or silence, not a nurture track.

Speed deserves an honest paragraph. The HBR data found that firms trying to contact a lead within an hour were nearly seven times as likely to qualify it as firms that waited even one more hour, and more than 60 times as likely as firms that waited a day or longer [1]. Two cautions. The data came from 1.25 million leads at 42 firms, and one of the authors was then CEO of a sales-acceleration software company, so read it as strong observational evidence, not an experiment. And the popular versions ("respond in five minutes or lose 21x" and "100x") trace to vendor-sponsored work, not to this paper; I do not use them. What survives is enough: interest decays in hours, and many companies still lose leads they paid for to plain neglect.

But speed is table stakes, not the product. An instant reply that ignores what Rosa wrote is just a faster way to sound like everyone else. The design target is the fastest *specific and true* answer, which in practice means minutes, with a human approving until the system has earned more autonomy (Chapter 18).

## What you need to know

Inbound signals come in four kinds, and they deserve very different trust.

1. **Declared**: form fields and, above all, free text. The most valuable personalization input in marketing is a sentence the customer typed, and most funnels throw it away. Extract it into typed facts with provenance (Chapter 8): technician count 38, branches 2, dispatcher vacancy, current tool "spreadsheet".
2. **Session context**: the pages read, the referrer, the campaign, the device. Useful for choosing what to show next; weak evidence about intent, because one visit is noisy.
3. **Inferred company**: reverse-IP lookup and enrichment. This names an organization, not a person, and is often wrong for remote workers, VPNs, mobile networks and shared offices. Treat it as a hypothesis with a confidence, never as identity (Chapter 9). A freemail address names no company and must not inherit the mail provider's firmographics; in the engine I built, a freemail lead suppresses company research and lowers the reply's specificity.
4. **Memory**: what Larkspur already knows. Is Cardinal a customer, a former customer, an open opportunity? Did another Cardinal employee fill a form last quarter? Is there an open ticket, an opt-out, a consent record? Match on strong keys: in the memory system I built, records resolve by email, website or a CRM id, a matching name alone never joins two records, and a merge stays reversible.

Buyers increasingly arrive late and informed. 6sense's 2025 buyer survey (vendor research) reports that buyers initiate first contact in about 79% of cases, at roughly 61% of the way through their journey [2]. Gartner's 2025 survey of 632 B2B buyers found 61% preferred a rep-free buying experience, 73% actively avoid suppliers that send irrelevant outreach, and 69% reported inconsistencies between a supplier's website and what its sellers told them [3]. Read together: by the time someone fills your form, they have done their homework, and the fastest way to lose them is to ignore it or contradict your own website.

The memory shape follows from that. A form fill is an **event attached to a person and an account**, not a new lead record. The anonymous session that preceded it is promoted to the known person only for the session that led to identification (Chapter 9: anonymous to known is a promotion, not a merge). The next step in the engine I built, a design rather than a result, carries one first-party session identifier from anonymous visit to form submit, so the pages read before the form join the lead's context. It links what one browser did on your own site; it never reveals who an anonymous visitor is. Account research is keyed to the company with a freshness window, so the second and third leads from Cardinal read the research the first one paid for (Chapter 17). Every fact carries its source, date, confidence and the surfaces it may appear on (Chapters 10 and 11), because the same fact that belongs in a rep's brief may not belong on a web page.

Identity confidence then sets the ceiling on what each surface may do:

| What you know | Evidence | What the website may do | What a message may say |
|---|---|---|---|
| Nothing but context | Referrer, campaign, page | Choose among approved variants by context | Not applicable |
| A probable company | Reverse IP, enrichment | Industry-level variant at most; never name the company | Not applicable |
| A person who told you | Form, typed email | Use what they declared, in pages linked to them | Their stated need; public account facts, sourced |
| A logged-in customer | Authenticated session | Account-specific content, within their permissions | Account history, within policy |

The table is Chapter 15's specificity ladder applied to the web: before identity, personalize to the campaign context; after it, to the person and the account. Enforce the row in code, not in a prompt, so the model cannot talk its way past it. The row decides how specific you may be; ambition does not.

![Four rising steps of identity confidence. Step 1, nothing but context (referrer, campaign, page): choose among approved variants by context. Step 2, a probable company (reverse IP, enrichment): an industry-level variant at most, never naming the company. Step 3, a person who told you (form, typed email): use what they declared, in pages linked to them. Step 4, a logged-in customer (authenticated session): account-specific content within their permissions. Steps 1 and 2 are anonymous and may use only public facts or what the visitor said this session; the row decides how specific you may be, not ambition.](/images/handbook/pb-m1-identity-ceiling.svg)

*Figure M1.1. The identity-confidence ceiling: each step of certainty about the visitor unlocks a little more, and anonymous pages never show account data.*

## The action

Three things happen after an inbound moment, on three clocks.

![A request arrives with form fields and free text and is first matched to memory: is this a customer, an open ticket, an opportunity, an opt-out? A customer or an open escalation goes to the account owner or support; a student, job seeker, competitor or vendor gets polite routing or silence. A real request is answered on three clocks: a first reply within minutes that answers the stated need and that a rep approves; a rep brief within minutes to an hour, where deep research lives, read by the rep and never sent; and a linked page built on lead acceptance, before the click, under automated checks. The reply and the page compile from the same context.](/images/handbook/pb-m1-inbound-three-clocks.svg)

*Figure M1.2. Match first, then answer: route or stay silent where that is right, and give a real request its reply, brief and page on three clocks.*

**The first reply (async, minutes).** An agent drafts it under a generation contract (Chapter 15) with a small number of typed zones: an opening that answers the stated need, one relevant proof point selected from an approved library, one question, one clear next step. The allowed evidence is what the person declared plus sourced, dated account facts; forbidden claims include prices, discounts, commitments, and anything learned from browsing ("I saw you on our pricing page"). A rep approves and sends it. Human approval at the start is not a bottleneck to remove quickly; it is where the system learns, because every edit is a labeled example of what it got wrong (Chapter 6). Loosen it by consequence tier as the edit rate falls.

**The rep brief (async, minutes to an hour).** Account snapshot, what the person said, what Larkspur already knows, what is unknown, and two questions worth asking. Deep research belongs here, where a person reads it before anything reaches the customer: research that takes minutes is a design decision, not a performance problem. Keep the boundary explicit: hypotheses and competitive context a rep may see must never reach the reply. In the engine I built, an explicit serializer decides what leaves the system, so a new internal field is never exposed just because someone added it.

**The website (real time, and mostly precomputed).** A page has a latency budget of a few hundred milliseconds of server time and a layout-shift budget of almost nothing (Chapter 17). So the live path selects; it does not think. For an anonymous visitor it selects among approved variants using context: the campaign that brought them, the industry page they came from. Campaign parameters already declare a persona, industry, region, message and offer; that alone picks a far better page than the default without identifying anyone. In the engine I built that mode is the next pilot: design, not result.

For Rosa, the page linked in her reply is generated and validated when the lead is accepted, before she clicks, so the click is a fetch. That is how the known-lead flow runs in the engine I built. The submission is acknowledged at once; in the background the page is generated into typed zones (hero, "for teams your size" section, relevant case study, next step), each with an approved fallback, inside a static shell for legal copy and navigation. Its inputs are read back before rendering, because a successful write is not always a readable one, and its link is checked before delivery. If only the page failed, only the page is rebuilt. It shows only what she declared plus public facts. Pricing stays the same for everyone; an adaptive pricing page is a separate, high-stakes decision Larkspur deliberately left on the whiteboard (Chapter 6). Chapter 16 places this page on the first rung of its Generative Experience Ladder and covers the render gate every zone passes before it is shown.

The page and the reply compile from the same context (one brain, many surfaces: Chapter 15's channel compilers). If the email says "two branches" and the page says "enterprise fleets," you have built one of Gartner's 69% [3].

The idea of a page that adapts to each visitor is older than language models. In 2009 Hauser, Urban, Liberali and Braun described "website morphing": inferring a visitor's cognitive style from clicks and switching the site's look and feel, estimating an almost 20% gain in purchase intentions from their model and data [4]. The newer version generates the interface itself. Google Research described generative UI in November 2025, deployed in experiments in the Gemini app and in AI Mode in Search: raters strongly preferred the generated interfaces over standard text answers, though human expert-designed websites still ranked first, and the authors note generation "can sometimes take a minute or more" with "occasional inaccuracies" [5]. For a marketing site, label it plainly: template-and-zone pages ship today; per-visitor generated pages are forecast. When they arrive, the same contract applies, because a generated page is a message with a layout.

Where this sits in the stack:

| Surface | What is generated | Timing | Approval |
|---|---|---|---|
| First reply | Zones of an email from a rep | Minutes after submission | Rep approves (initially all; later by tier) |
| Rep brief | Research synthesis, questions | Minutes to an hour | Read by the rep; never sent |
| Linked landing page | Zones filled from declared and public facts | On lead acceptance, before the click | Automated checks; sampled QA |
| Anonymous visit | Nothing; selection among approved variants | Real time | Variants approved in advance |
| Nurture | Next resource or nothing, per person | Scheduled | Contact budget arbitration (Chapter 14) |

## What can go wrong

**Failure story: The Billboard.** Larkspur's first web personalization vendor offered "account-based" pages: resolve the visitor's IP to a company, then tailor the hero. Someone configured it to use CRM fields. For a month, anyone whose connection resolved to Harlow Fleet Services, an existing Larkspur customer, saw "Built for Harlow's 400 technicians: see what's new in your plan." Harlow's office shared a building network with other tenants, so the page greeted a visiting competitor's sales engineer with Harlow's seat count and customer status. Nothing was false. It was customer data published to an unauthenticated surface on the strength of an IP address. The rule that fixes it is short: **an anonymous page may use only what is public or what the visitor told you in this session.** Account-specific content belongs behind a login or in a link sent to a verified person.

The other risks, in rough order of frequency:

- **Narrating the visit.** "Saw you were checking our pricing" is accurate and still fails Chapter 19's say-how-we-know test. People do not object to being known; they object to discovering they were watched. Aguirre and colleagues found overt data collection raised click-through on personalized ads while covert collection raised feelings of vulnerability and lowered it [6].
- **The confident wrong detail.** A first reply that invents a company event, or confuses Cardinal Mechanical with a similarly named firm (Chapter 15's failure story). Or one that tells a former customer "your current plan includes this." Entity-confidence gates on research, grounding checks on every personal claim, no relationship statement unless memory confirms it, and an honestly general fallback that steps down: person and account, account, segment, approved static copy, nothing.
- **Two voices.** Marketing enrolls the lead in nurture while sales is mid-conversation, or a customer's form fill starts a new-logo sequence. One arbitration point, one contact budget (Chapter 14; Playbook P9).
- **The broken page nobody read.** Late-arriving personalization that shifts the layout, or a hero showing a raw template fragment, the kind of defect Chapter 20 found only by scanning every rendered page rather than a sample. Stored fields can be right while the live page is wrong (a stale template or cache, the wrong page identity), so review the page a visitor sees.
- **Pressure dressed as personalization.** Countdown timers, invented scarcity, "three people from your company are viewing this." Excluded by policy, not by taste: write the prohibition into the contract (Chapter 18). Chapter 3 traces these deceptive patterns and why tuning them per person makes them harder to see.
- **Consent and channel rules.** Whether you may email the person at all, and how, depends on where they are and what they agreed to (Chapter 19). A demo request is consent to answer the demo request, not to a newsletter everywhere.

**What this does not do.** A faster, truer reply does not create demand; it stops you losing the demand that already arrived. And it does not make the anonymous website personal: until a visitor tells you who they are, choosing among approved variants by context is the ceiling.

## How you will know

Pick one primary outcome that is close to value but frequent enough to measure: **meetings held per inbound request**, or qualified opportunities per request. Not replies and not open rates (Chapter 21: an open rate is not an outcome). Track **time to first specific answer** as a process metric, and three guardrails: reader-flagged errors, unsubscribes and complaints from inbound contacts, and page Core Web Vitals on personalized pages.

Test design, with Larkspur's illustrative volumes. Chapter 6 put inbound at about 3,000 demo requests a year. Randomize at the request level: half get the new flow (agent-drafted, rep-approved, linked page), half the old one. To detect a close-rate change from 20% to 23% with standard settings (5% significance, 80% power) you need roughly 2,900 requests per arm: two years of Larkspur's volume. Detecting meetings held moving from 30% to 36% needs roughly 960 per arm, about eight months at a 50/50 split. So measure the nearer outcome, keep the test running long enough, and follow the treated cohort through to pipeline for the long-run check. Say plainly which effects your volume cannot detect.

For anonymous website personalization, randomize visitors (or accounts, when account-level variants are involved) and keep a small permanent holdout that always sees the default site. Set expectations with Kohavi's warning from Bing: only about 10 to 20% of tested ideas improved their target metric, and most winners moved it by 0.1% to 1% [7]. A page variant that "lifts conversion 40%" in week one usually has a bug, a novelty effect, or a tiny sample (Twyman's law, Chapter 21).

## Reader Q&A

**Should we buy a website personalization tool first?** Not first. Fix the inbound response path, which has the most declared evidence and the clearest outcome. Web personalization for anonymous visitors works on the weakest evidence you have.

**Is putting the first name in the subject line worth it?** It measurably helped in Sahni, Wheeler and Chintagunta's randomized field experiments (Chapter 1) [8]. It is also the shallowest thing you can do. Do it, then answer what they wrote.

**Can an AI reply instantly without a human?** For acknowledgment and scheduling, yes. For anything that makes a claim about the person's business, start with approval and remove it by consequence tier as the edit rate falls.

## For your AI

```yaml
playbook: M1
title: "Marketing I: Inbound and the Website"
question: "They came to us. What should they see and receive next?"
foundation_links: [6, 8, 9, 10, 11, 14, 15, 16, 17, 18, 19, 20, 21]
concepts:
  - name: Customer went first
    definition: "An inbound request is a stated need to be answered; personalization starts from what the person declared, not from what was inferred about them."
  - name: Identity-confidence ceiling
    definition: "What a surface may personalize is capped by how well the visitor is identified: context only, probable company, declared person, authenticated customer."
  - name: Declared-first evidence
    definition: "Form fields and free text are extracted into typed facts with provenance and outrank inferred company data."
  - name: Select live, generate ahead
    definition: "Website personalization on the live path selects among approved or precomputed variants; generation happens asynchronously before the click."
  - name: Context before identity
    definition: "Before identity, personalize to campaign context (persona, industry, region, message, offer); after identity, to the person and account."
decision_rules:
  - if: "the lead uses a freemail address or company identity is otherwise weak"
    then: "suppress company research and firmographics; use lower-specificity copy"
  - if: "a customer-facing zone states a relationship (current plan, renewal, product owned)"
    then: "block it unless the relationship is known in memory; otherwise reframe as an evaluation"
  - if: "only the personalized page failed"
    then: "rebuild the page alone and verify its link; do not rerun the pipeline"
  - if: "a visitor is not authenticated or verified"
    then: "use only public facts and what the visitor told you this session; never display account data or an inferred company name"
  - if: "an inbound request comes from an existing customer or an account with an open escalation"
    then: "route to the account owner or support; do not enroll in a new-customer sequence"
  - if: "the request contains free text"
    then: "extract it into typed facts with provenance and make the first reply answer it"
  - if: "a first reply makes any claim about the person's business"
    then: "require rep approval until the measured edit rate for that zone falls below the agreed threshold"
  - if: "company identity comes only from reverse IP or enrichment"
    then: "treat it as a hypothesis; allow industry-level variants at most"
  - if: "a proposed page element uses urgency, scarcity, or narrates the visitor's browsing"
    then: "reject it at the contract level"
  - if: "annual inbound volume cannot detect the target effect on close rate"
    then: "measure a nearer outcome (meetings held) and follow cohorts to pipeline"
assessment_questions:
  - "What is your median and 90th-percentile time to a first reply that addresses what the person wrote?"
  - "Do form free-text answers reach the rep and the reply, or are they discarded?"
  - "Is a form fill matched to existing accounts, open opportunities, customers and open tickets before routing?"
  - "What does your website show an anonymous visitor based on reverse IP, and could it expose customer data?"
  - "Do the reply, the landing page and the rep read the same customer context?"
  - "How many inbound requests do you receive a year, and what effect size can that volume detect?"
patterns: [Declared-First Reply, Identity-Confidence Ceiling, Precompute-then-serve, Generation Contract, Do-Nothing Option]
anti_patterns: [The Billboard, Narrating the Visit, Fast and Generic, Two Voices, The Hallucinated Detail]
metrics:
  primary: "meetings held per inbound request (or qualified opportunities per request)"
  process: "time to first specific answer"
  guardrails: ["reader-flagged errors", "inbound unsubscribes and complaints", "Core Web Vitals on personalized pages"]
maturity_dimension: experience_generation
```

## References

1. Oldroyd, J. B., McElheran, K., and Elkington, D. (2011-03). "The Short Life of Online Sales Leads." *Harvard Business Review*. https://hbr.org/2011/03/the-short-life-of-online-sales-leads
2. 6sense (2025). "2025 Buyer Experience Report." Vendor research. https://6sense.com/science-of-b2b/buyer-experience-report-2025/
3. Gartner (2025-06-25). "Gartner Sales Survey Finds 61% of B2B Buyers Prefer a Rep-Free Buying Experience." https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-sales-survey-finds-61-percent-of-b2b-buyers-prefer-a-rep-free-buying-experience
4. Hauser, J. R., Urban, G. L., Liberali, G., and Braun, M. (2009). "Website Morphing." *Marketing Science* 28(2):202-223. https://pubsonline.informs.org/doi/10.1287/mksc.1080.0459
5. Leviathan, Y., Valevski, D., Natchu, V., and Matias, Y. (2025-11-18). "Generative UI: A rich, custom, visual interactive user experience for any prompt." Google Research. https://research.google/blog/generative-ui-a-rich-custom-visual-interactive-user-experience-for-any-prompt/
6. Aguirre, E., Mahr, D., Grewal, D., de Ruyter, K., and Wetzels, M. (2015). "Unraveling the personalization paradox." *Journal of Retailing* 91(1). https://www.sciencedirect.com/science/article/abs/pii/S0022435914000669
7. Kohavi, R., and Longbotham, R. (2007), "Online Experiments: Lessons Learned," *IEEE Computer* 40(9), and Kohavi et al. (2014), "Seven Rules of Thumb for Web Site Experimenters" (KDD slides). https://exp-platform.com/Documents/2014-08-27ExperimentersRulesOfthumbKDD.pdf
8. 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