Anatomy of a Moment

Three visits. One account. Seven days.

Someone read our pricing page on a Tuesday morning. Wednesday afternoon they were back, on the comparison page this time, weighing us against the alternative they are presumably shortlisting. The following Monday, pricing again. Same account.

Name it by its parts: pricing → comparison → repeat (7d).

That is a moment. Somebody inside that account is building a case, or losing an argument, and your pricing page is the exhibit. What has to happen next is a relevant touch, and it has to land while the case is still open. That clock is measured in hours. Maybe a day.

Here is what took me too long to admit: for most of Civic's life, our own signal-to-touch chain ran signal → Slack ping → spreadsheet row → standup → touch, and on a good week it cleared in three days. I called that operational discipline. It was a relay race where every runner had a day job.

In part 1 I argued the why: tokens are dead weight, the moment is the scarce input. This note is the mechanics. What actually has to happen, in order, between the signal firing and the touch landing. There are six stages. Every one of them is a place teams silently fail, quietly enough that the funnel report never names the leak.

One moment, six parts. Every number illustrative, not a benchmark.

01 · The signal

What fired

pricing Tue 09:41
→ comparison Wed 14:03
→ repeat Mon 09:12

The window

7 days. The same three visits spread across a quarter would be trivia. Inside the window they are a decision being made.

02 · Identity

Resolved to

acct_4471 · an infra-monitoring company, 40 to 200 people · reverse-IP + CRM domain match

Confidence (illustrative, not a benchmark)

0.86

Resolution is probabilistic. Below your stated floor, the honest move is to treat the visitor as anonymous and respond to the behavior alone.

03 · The score

Three axes, weighted (illustrative, not a benchmark)

fit 0.74 × 0.33

intent 0.86 × 0.41

timing 0.70 × 0.26

weighted 0.78 vs threshold 0.70 · cleared

04 · The Play

pricing-follow-up-v2 · APPROVED

Trigger

the stage 1 pattern, exactly as written

Qualify

score clears the 0.70 threshold

Action

send the pricing answer the comparison page leaves open

Destination

your sending tool, named. Authority lived here, at definition time. The run is an execution, not a decision.

05 · The bounds

Named channels

email only

Usage limit

run 14 of 200 this month

Suspend

instant, global

A suspend that finishes the current batch first is a confession.

06 · The record

Mon 09:19 · I ran pricing-follow-up-v2 against acct_4471
seen: pricing → comparison → repeat (7d) · score 0.78 vs 0.70
sent: 1 email, named channel · run 14 of 200 · replied Tue 08:52

What was seen, why it qualified, what happened. One line, first person, no drama. This is what makes the other five stages inspectable.

Step with the buttons or pick a stage (arrow keys work).

Stage 1: the signal

What fired, and inside what window. Both halves matter, and the second one is the half teams skip.

The visits are facts. Pricing on Tuesday, comparison on Wednesday, pricing again on Monday. But a signal without a window is trivia. Three pricing visits spread across a quarter describe a company that occasionally remembers you exist. The same three visits inside seven days describe a decision being made. pricing → comparison → repeat is the melody. (7d) is the tempo, and the tempo is the meaning.

Most teams fail this stage by collecting signals without windows. The intent dashboard shows everything that ever happened, sorted by recency, which is the same as showing nothing. If you cannot say what pattern, inside what window, counts as a moment for you, you have analytics. You do not have stage one.

Stage 2: identity

Who is this. The honest answer, most of the time, is: probably someone.

Identity in this business is partly rented. Reverse-IP vendors, enrichment providers, a CRM domain match if you are lucky. Stitched together, they resolve our Tuesday visitor into something like an infra-monitoring company, 40 to 200 people, with a contact already in the CRM from a webinar two quarters back. Useful. Also probabilistic. The readout should say so: acct_4471 · confidence 0.86 (illustrative, not a benchmark) is a claim you can act on. "Definitely Dave from ops" is a claim your vendor invented to feel useful.

Pretending resolution is certain is how "personalization" ends up emailing a bot, a scraper, or a competitor on a research errand. The mature version of this stage carries its own doubt: above a stated confidence, act on the resolved account; below it, treat the visitor as anonymous and respond to the behavior alone, or not at all. The failure mode is not low confidence. It is unreported confidence.

Stage 3: the score

The account is real and the pattern is live. Qualified against what?

Against your ICP, on three axes. Fit: is this the kind of account you actually sell to. Intent: is the behavior a buying behavior or a browsing one. Timing: is it happening now, inside the window, or is it archaeology. Each axis gets a value, each value gets a weight, and the weighted sum either clears a threshold you set or it does not.

The requirement here is transparency, not sophistication. If the tool cannot show you the axes, the weights, and the threshold, you do not have a score. You have a mood with decimal places.

Example account: acct_4471, an infra-monitoring company. Axis values fixed at fit 0.74 · intent 0.86 · timing 0.70. All values illustrative, not a benchmark.

Worked example: weights normalize to fit 0.33 · intent 0.41 · timing 0.26, giving a weighted score of 0.78 against a 0.70 threshold. Cleared. Raise the threshold to 0.80 and the same account misses; shift the weight from intent to fit and the score drops. The threshold is a policy you write, not a feeling the software has.

Drag the sliders (arrow keys work). Same account, your policy: every part of this is visible and yours to set. Illustrative, not a benchmark.

Move the weights and watch the same account clear or miss. That is the point of the exercise: the threshold is a policy you wrote, not a feeling the software had. When someone asks why an account was touched, "it scored 0.78 against a 0.70 threshold, weighted like this" is an answer. "The model liked it" is not.

Stage 4: the Play

Now something has to happen, and this is where the authority question lives. Not at 9:12 on a Monday when the third visit lands. Weeks earlier, at definition time, when you decided: this trigger, these qualification rules, this action, this destination.

A Play is that decision, written down and approved. The trigger is the pattern from stage one. The qualification is the threshold from stage three. The action is specific: send the pricing answer, the one that addresses what the comparison page leaves open. The destination is named: this sending tool, this sequence, nothing else.

The run is not a decision. It is an execution of a decision you already made, with your name on it. That distinction sounds pedantic until you are the one accountable for what went out on a Monday morning while you were in a board meeting.

Stage 5: the bounds

An execution layer with no bounds is a liability with a roadmap.

Bounds are three things, and they are boring on purpose. Named channels: the Play writes to the systems it names and touches nothing else. Usage limits: a cap on runs, so one noisy Tuesday cannot spend a month of channel goodwill before lunch. And a suspend that suspends: one control, global, immediate. Not a suspend that finishes the current batch first. That one is a confession.

Teams fail this stage in the optimistic direction. Nobody plans bounds for the tool that is working. Then it works twice as hard as expected, and the bound you never set gets discovered by your deliverability.

Stage 6: the record

Every run writes down what was seen, why it qualified, and what happened.

I ran pricing-follow-up-v2 against acct_4471, plus the signal that fired and its window, the score against the threshold, the channel it went out on, and the outcome. One line, first person, no drama.

The record is not compliance theater. The record is what makes the other five stages inspectable. When a touch lands well, you can see exactly why it went. When a touch should not have gone, you can trace which stage let it through: a window too wide, a confidence too generous, a threshold too low. Without the record, every one of those is a shrug. I made the longer version of this argument in Proof of Claims: claims are cheap, receipts are the product.

Run it backward

Here is the exercise this note exists to hand you. Take one account that went cold last month and run the six stages in reverse. Is there a record of anything being seen? Was there an approved action ready, with bounds, or would a touch have been improvised on the spot? Would the behavior have scored against your ICP, on axes you can name out loud? Did you know who it was? And do you know, even now, what fired and when?

Wherever the chain breaks first, that is your mechanics gap. In my experience it breaks at stage one more often than anyone admits: the signal fired into a tool nobody was watching that afternoon, and the moment expired with a green checkmark next to it.

Six stages, by hand

Now run the whole chain by hand, in minutes, for every moment. Someone watching every signal source with the windows in their head. Someone resolving identity and remembering which confidences to distrust. Someone scoring against the ICP consistently at 9:12 on a Monday. Someone matching the right pre-approved response, checking the caps, and sending. Then writing it all down.

That is a full-time watcher per segment, minimum. In practice it is one overloaded person doing all six stages for the loudest segment and zero of six for everything else. Teams do not fail at moment personalization because they are lazy. They fail because six-stage clearance in minutes was never a reasonable ask of a human calendar. It is a staffing problem wearing a discipline problem's clothes.

This is the job Bryn does. Bryn is the governed execution layer that runs Plays through your stack: it watches the systems you connect, scores what fired against your ICP on the same three axes with the weights on display, and runs the Play you approved into the channels the Play names, inside usage limits, under a global suspend, with a per-run record of what was seen, why it qualified, and what happened. The six stages do not get skipped. They get cleared while the moment is still a moment, the way we run it on our own funnel. Bryn watches. You decide the Play. Bryn runs it.

Part 2 of 3

Part 1 was the why: tokens are free, moments are scarce. This was the how: six stages between the signal and the touch, and a chain that breaks silently at whichever stage you never staffed. Part 3 is the proof: what to count, what to ignore, and why open rates will lie to you about all six stages at once.

The moment from the cold open is not exotic. Some version of pricing → comparison → repeat (7d) fired against your funnel this week. The only question is how many stages it cleared.

Stop watching signals. Start running them.

---

Further reading

• The {FirstName} Fallacy (Civic Field Notes): part 1 of this series, the why, with the response-time evidence this note leans on.
• Proof of Claims (Civic Field Notes): the longer argument for receipts over claims.
• We Are Customer Zero (Civic Field Notes): how we run Bryn on our own funnel.
• Bryn: the governed execution layer that runs Plays through your stack.