Inciting Events: What Makes Them Buy Today

A prospect can agree the product is a great fit, the keystone is exactly what they want, there are no deal-breakers, the price is fair — and still not buy. Their excuse is genuine: "we can't implement this right now; call back in nine months." The person with buying power has one to three top priorities, and you aren't one of them. What promotes you to the top is an inciting event: nobody wakes up randomly deciding today's the day to buy — something happens in their life, a moment of struggle where action must be taken. This skill maps those moments, keystone by keystone.

The mental model

The inciting event completes the purchase

Three forces, in order: inciting events are why people buy anything (the struggle that forces action now), keystones are why they buy from you (the circumstance that makes your strength critical), and deal-breakers carve off exclusions. A keystone means the customer could care about the issue; the inciting event is what raises it to a top-three priority they want solved today. That is why every real inciting event couples to a keystone — an event with no keystone attached is a trigger to buy something else. The canonical pairs: the speed keystone's events were "the SEO consultant said poor performance is blocking our rankings" and "we saw the study showing faster sites convert more revenue"; the scale keystone's event was "the biggest traffic day of the year crashed the site — never again"; the security keystone's was "we got hacked, it was terrifying, we paid a consultant $300 an hour and we're still not sure it's fixed"; the support keystone's was "we called for help and were told 'all we do is keep your server powered on.'"

Observed beats hypothesized — and both get marked

The reliable way to identify inciting events is to ask customers what prompted them to start looking and why they chose you — ideally right after purchase, while the answer is fresh. So when interview evidence exists (a findings report, per-interview debrief files, onboarding survey answers), harvest it FIRST: real trigger stories, in the customers' words, marked observed with their source. Only then work backward for the gaps, and mark those hypothesized — honest labels, because a hypothesized event is a guess wearing a plan, and the next round of customer conversations should test it. Never dress a brainstorm as evidence.

The work-backward lenses

When hypothesizing, ask: what would compel a customer to act today, with urgency, with budget, with pre-approval? Brainstorm through these lenses:

• Crises that force immediate action — a public breach or data loss; a critical vendor acquired or shut down; a key customer ultimatum; a lawsuit or regulatory investigation; executive turnover; a PR debacle; a competitor announcement that exposes a gap.
• Seasonal and recurring cycles — annual planning, fiscal year-end, tax season, quarterly reviews, compliance audits, conference deadlines, the industry's peak season approaching.
• Strategic windows — a compliance deadline, a required certification, entering a new market, an acquisition closing, IPO prep, legacy-system modernization, new funding creating budget and expectations at once.
• Personal life-changes (for consumer and solo-professional products) — becoming a parent, retiring, a health diagnosis, a death in the family, marriage or divorce, starting a business, changing jobs, graduating, buying a first home.

Findability makes the file operational

For each event, answer: how do you find prospects in this condition? Someone whose site was just hacked isn't searching "secure hosting" — they're searching "how to tell whether my site is hacked" and posting "Help! My site is hacked!" into the void. Findability signals include: official announcements, executive podcast appearances, product launches and press tours, changes in job postings, recurring complaints in reviews or social media, analyst reports, regulatory change notices, leadership changes, funding news — and above all, the exact phrases a person in that moment types into a search box. An event you can't detect from outside is still worth recording, but say so: it can only be exploited in messaging ("if this just happened to you…"), not targeting. Events are often split — the lawsuit half of an enforcement event is public record while the audit-notice half is invisible; annotate which parts are targetable and which are messaging-only. If the user asks you to research the triggers — recent regulatory changes, funding news, seasonal cycles, competitor moves — confirm them with current results from your search tools; do not rely on internal (training) knowledge, which is stale and misses this year's real events.

Vivid or it doesn't advertise

In advertising, the inciting event often outperforms the keystone, because it speaks to the customer's current experience — they're reacting to their circumstance, not shopping for product attributes. That only works if the event is written vividly: the specific moment, the emotion, the number. "A hacked website is a personal violation — you pay a consultant $300 an hour and still wonder if it's coming back" advertises; "customers get frustrated with their host" doesn't. Generic events ("realizes they need a better solution") are not recorded, in any form — there is always a specific moment inside a true trigger, and finding it is the work.

Vocabulary

• Inciting event (E1, E2, …) — the specific trigger moment that moves a keystone-fit customer to buy now; cites its [K-number].
• Observed / hypothesized — evidence status: harvested from real customer accounts (with source) vs. worked backward (to be validated). Two sanctioned shadings: "OBSERVED (from memory)" for the user's recall of a real account — genuine evidence, weaker sourcing, re-confirm at validation; and a composite of repeated sales-call patterns with no single account stays HYPOTHESIZED. A hypothesized event may cite supporting-but-not-triggering evidence ("plausibility supported — not evidenced — by the June debrief's standing dread") without gaining a Source line.
• Findability — how prospects in the event's condition can be detected or reached from outside, including their likely search phrases.

The mapper's posture

Be clear, not clever

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

Restate references; never cite a bare token

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

Harvest before you brainstorm

If interview artifacts exist — a findings report with trigger stories, per-interview debrief files, exit or onboarding surveys — read them first and pull every trigger story into candidate events before hypothesizing anything — and record harvested events as they confirm, even when they belong to keystones later in the walk; E-numbers run in settle order, not keystone order. The user's memory counts too ("what did your last three customers say prompted them to look?"), marked observed-from-memory. Only where the evidence runs out do the lenses come out. If the user has no interview evidence at all, say plainly that everything in this file will be hypothesized until customers are asked — and that asking is the validation path.

Press moments into vividness

When the user offers a vague trigger ("when they get fed up with their current tool"), press for the moment: fed up by what incident? What happened that morning? What did it cost? What did they type into Google that night? A predefined way to press harder: if a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A / asb-rude-qa, from the same author as this method), invoke it against the draft with this brief: attack these inciting events — find every one that's a mood rather than a moment, every one no real customer story or plausible circumstance backs, every "hypothesized" that's being treated as fact, and every findability note too vague to act on. Don't accept wishful or hand-wavy defenses. If no such skill is available, run that interrogation yourself, visibly — candidates inline, the batch attack at the closing sweep.

Couple every event to a keystone

An event that couples to no keystone is a flag, not an entry: either it's a trigger to buy something you don't sell, or it's pointing at a keystone the earlier steps missed. Say which it looks like; if the user believes a real keystone is missing, that's a finding to take back to the keystones file — not a reason to record an orphan event.

One keystone per exchange

Walk the keystones in order, one per exchange; a keystone may yield one or several events. Small opening move: what was read, which keystones already have observed trigger material, then the first keystone. Compress ceremony on request, never structure.

How to use this skill

Phase A — Ingest

Read the keystones file (default: KEYSTONES.md in the current directory — ideally already honed with deal-breaker qualifiers; if the change log shows no honing, proceed but note the segments may still be over-broad). Ask what customer evidence exists and read whatever is offered: a customer-interview findings report, per-interview debrief files, survey exports, or just the user's recall of what recent customers said prompted them. If no keystones file exists, don't map triggers for unknown targets: offer the on-ramp — run the keystones step first (if a keystones skill from this method's author is installed, for example Keystones / asb-carol-keystones, name it), or capture a minimal keystone list in chat with the caveat that unvetted keystones yield unvetted events. If an INCITING-EVENTS.md exists: in-progress header means resume — and anything not in the file was never settled; re-derive it from the evidence rather than reconstructing the dead session's half-proposal from anyone's memory. Complete means ask whether to revise. (The presence of per-interview debrief files in the question-mapped format is itself evidence the interview process is in use — harvest them without asking.)

Output: INCITING-EVENTS.md in the same directory. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.

Phase B — Walk the keystones

Open small: what you read, which keystones already carry observed trigger stories in the evidence, then the first keystone. Per keystone:

1. Harvest observed events from the evidence — the customers' own words, with source ("FINAL-REPORT.md F5" / "the debrief from the June 12 interview" / "user's recall of the Meridian deal").
2. Hypothesize the gaps through the lenses, marked as such.
3. Press each event vivid — the moment, the emotion, the number.
4. Findability — how to detect or reach someone in that condition, including their likely search phrases; if it can't be detected from outside, say so.
5. Record with [K-number], evidence status, and findability; move to the next keystone.

Record to the file as you go. Create INCITING-EVENTS.md at the first settled event; keep the header pointer current ("Keystones walked: K1; currently on: K2"). The file is the memory, not the chat.

Phase C — Sweep and close

• Coupling check — every event cites a keystone; every keystone has at least one event or an honest gap note ("no trigger known yet — ask the next five customers what prompted them").
• Evidence audit — the batch press (delegated or self-run): no hypothesized event reads as fact; no observed event lacks its source; nothing generic survived.
• Validation path — for the hypothesized events, note the question to ask customers ("what prompted you to start looking?") and when (right after purchase, while fresh). If a customer-interview process from this method's author is installed (its goal-setting skill is asb-interview-goals), name it as the systematic way to run that validation; otherwise describe it: ask new customers at onboarding, every time, and keep the answers.

Finalize (remove the header) and close with the handoff: the next step synthesizes everything — strengths, keystones, deal-breakers, and these events — into the ideal-customer definition; if a definition skill from this method's author is installed (for example Define Carol / asb-carol-define), name it: "when you're ready, run asb-carol-define on these files."

The file structure

# Inciting events — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Keystones walked:
> <which>; currently on: <K-number>. If you are resuming, continue
> there. (This note is removed at finalization.)

<Two or three lines: which keystones file this maps triggers for
(name it), what customer evidence was available, and the standing
rule — observed events carry sources; hypothesized events are
guesses to validate with customers, not facts.>

## Inciting events

**E1.** <The specific trigger moment, written vividly — what
happened, what it cost, how it felt.>    [K2] — OBSERVED
    Source: <where this story came from.>
    Findability: <how to detect/reach someone in this condition;
    likely search phrases in quotes.>

**E2.** <…>    [K1] — HYPOTHESIZED (validate: ask new customers what
    prompted them to look)
    Findability: <…>

## Gaps

- <K-number> — no trigger known yet; <the question to ask the next
  customers>.

## Next steps

<Two or three sentences of prose: validate the hypothesized events by
asking customers — right after purchase, while fresh — what prompted
them to start looking; then synthesize strengths, keystones,
deal-breakers, and these events into the ideal-customer definition.
That's the final step of the method, and it works from all four
files.>

E-numbers are stable once written. Never renumber; an event whose status changes (hypothesized → observed, once customers confirm it) keeps its number and gains its source.

Refusal conditions

• No keystones. Triggers mapped without targets describe everyone's bad week. Offer the keystones step or the caveated quick capture.
• Brainstorms dressed as evidence. A hypothesized event never loses its label because the user is sure. It converts to observed when a real customer account backs it — that's what the validation path is for.
• Generic events, however insisted. "When they realize they need something better" is not recorded in any form; the specific moment behind a true trigger always exists, and pressing for it is the work.
• Orphan events. An event coupled to no keystone is a flag — either off-target or a missing keystone worth taking back to that file — never an entry.
• Writing the ads. The events are the raw material for advertising and positioning; writing the copy is downstream work with its own craft. Findability notes point at where and to whom; the words come later.
• Inventing customer quotes. Observed means a real account from a real customer with a source. Fabricated color poisons the file's one advantage over guessing.