<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
  <title>Jeff Nolan</title>
  <link>https://www.jeffnolan.com/</link>
  <description>Marketing executive. Systems builder.</description>
  <item>
    <title>No artifact, no handoff: the five-gate campaign lifecycle</title>
    <link>https://www.jeffnolan.com/writing/five-gate-lifecycle/</link>
    <guid>https://www.jeffnolan.com/writing/five-gate-lifecycle/</guid>
    <pubDate>Tue, 10 Nov 2026 00:00:00 GMT</pubDate>
    <description>One owner, one artifact, one gate per stage.</description>
    <content:encoded><![CDATA[Campaigns take months, and most of that time is handoffs. The fix is a five-stage lifecycle: Strategic Brief, Adaptation, Build and Produce, Launch and Execute, Report and Learn. Each stage has one owner, one required handoff artifact and one gate.

```yaml
stage: strategic-brief
owner: "{{TODO: role}}"
artifact: brief.json
gate:
  required: [audience, objective, offer, messaging_tier, success_metric]
  on_fail: return_to_owner
```

No artifact, no handoff. In software, the artifact is structured data and the gate is a check.]]></content:encoded>
  </item>
<item>
    <title>Agents as a workforce</title>
    <link>https://www.jeffnolan.com/field-guides/agents-as-a-workforce/</link>
    <guid>https://www.jeffnolan.com/field-guides/agents-as-a-workforce/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>The operating model is the process. Five agent lanes are how that process gets built and deployed, and the guardrail that stops an agent.</description>
    <content:encoded><![CDATA[## The problem

Most teams add agents the way they add tools. Someone finds one that works, a few people start using it, and six months later nobody can say what it owns, who checks it, or what it is never allowed to touch.

That is not a workforce. It is a pile of helpers. The first time one of them ships a wrong claim, the team learns to distrust all of them.

The operating model comes first, and it is a process. Stages. One artifact at each handoff. One gate. Messaging split into what is locked, what can be adapted, and what is free to write. Casting that process as an agentic system does not skip the process. An agent with no stage to run is just a faster way to improvise.

The point of an agent is to take repetitive work, so people spend their time on strategy, judgment, customers, and creative. Agents add a layer. They do not replace the team, and they do not replace the lead model already running.

## The system

Build the process, then put agents on it, then deploy them in an order that can be stopped.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Process</span></li>
<li><span class="jn-label">2</span><span>Memory</span></li>
<li><span class="jn-label">3</span><span>Agents</span></li>
<li class="is-now"><span class="jn-label">4</span><span>Evaluation</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 7h14"/><path d="M7 12h10"/><path class="is-mark" d="M9 17h6"/></svg>The process is the foundation</h3>

A campaign already has a path. A person writes the strategic brief and a person signs it. The brief has an objective, an audience, messaging, success metrics, a timeline, and a budget. Then adaptation. Then build and produce. Then launch and execute. Then report and learn. Each stage ends in a gate, and each gate has an artifact. No artifact, no handoff. That rule applies to an agent the same way it applies to a person.

<ol class="jn-stages">
<li><span class="jn-label">Brief</span><span>A person writes it and signs it.</span></li>
<li><span class="jn-label">Adapt</span><span>Inside the tier.</span></li>
<li><span class="jn-label">Build</span><span>Produce the work.</span></li>
<li><span class="jn-label">Launch</span><span>Execute.</span></li>
<li><span class="jn-label">Learn</span><span>The report, then the next brief.</span></li>
</ol>

Messaging has three tiers. Locked messaging is used as written. The agent may choose what to emphasize. It may not rewrite it. Flexed messaging can be adapted inside the argument, and a person approves it before it ships. Free messaging can be written for a local follow-up, inside the guidelines, and the draft is logged.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="6" y="10" width="12" height="9" rx="1"/><path class="is-mark" d="M9 10V8a3 3 0 0 1 6 0v2"/></svg><span><span class="jn-label">Locked</span>Used as written. The agent may emphasize it, not rewrite it.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 16l4-8h2l4 8"/><path class="is-mark" d="M7 13h6"/></svg><span><span class="jn-label">Flexed</span>Adapt the argument. A person approves before it ships.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 8h8M6 12h12"/><path class="is-mark" d="M6 16h9"/></svg><span><span class="jn-label">Free</span>A local follow-up, inside the guidelines, and logged.</span></li>
</ol>

If the stage, the artifact, and the tier are not written down, do not put an agent on the work. You would be automating a meeting that has not been designed yet.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="6" cy="8" r="2"/><circle cx="12" cy="8" r="2"/><circle cx="18" cy="8" r="2"/><circle cx="9" cy="16" r="2"/><circle class="is-mark" cx="15" cy="16" r="2"/></svg>Five lanes</h3>

Five agents cover the campaign. Each one gets a lane in one sentence, and a person who approves it. If either is missing, it does not go live.

<ol class="jn-stages">
<li><span class="jn-label">1</span><span>Intake</span></li>
<li><span class="jn-label">2</span><span>Decomposition</span></li>
<li><span class="jn-label">3</span><span>Steward</span></li>
<li><span class="jn-label">4</span><span>Rollup</span></li>
<li class="is-now"><span class="jn-label">5</span><span>Governance</span></li>
</ol>

Intake takes a finished brief, or a ranked piece of work, and nothing else. It does not turn every signal into a task. A customer-confirmed need gets help. A verified change gets a short look. A single inferred visit gets no agent task at all. High-fit accounts with no signal still get a person's attention, because waiting on a score is the dependency you were trying to leave.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 12h8"/><path class="is-mark" d="M12 8l4 4-4 4"/></svg><span><span class="jn-label">Confirmed</span>The customer confirmed the need. Give help.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M12 8v5"/></svg><span><span class="jn-label">Verified</span>A real change. A short look, not a campaign.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M9 9l6 6M15 9l-6 6"/></svg><span><span class="jn-label">Inferred</span>One visit. No agent task.</span></li>
</ol>

Decomposition reads that brief and breaks it into tasks. It drafts inside the tier it was given. It does not invent facts, and it does not open a new value proposition.

Steward keeps routine facts current. Status. Dates. What moved. It may write those updates on its own only after it has a record of being right. Until then, a person checks them.

Rollup writes the report of what changed and puts the learning where the next brief can use it. A person reads the report and writes that next brief. The loop does not close by itself.

Governance sits on the gates. It is the lane that stops the others. It checks the tier, the citation, and the never-do list. It does not ship the work. A person does.

The path is short. A person signs the brief. Intake accepts it. Decomposition drafts the tasks. Governance holds anything that is not allowed. A person approves. The work runs. Steward keeps the routine record current. Rollup brings the learning back. A person writes the next brief.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 6h12v4H6z"/><path d="M5 12h14v4H5z"/><path class="is-mark" d="M7 18h10"/></svg>Build, then deploy</h3>

I would build in four moves, and I would not swap them.

Process first, as above. Then memory. One identity for the account across the sources. A schema written down before anything is loaded. A citation on every fact, so a later agent can tell a customer-stated fact from a sales report, an approved line, a figure from analytics, an inference, and a fact that is old or unverified. Then the five agents, on that process and that memory. Evaluation last, and it is not optional. Without it you can see that the system is running. You cannot see that it is working.

Two more rules sit inside that order. Who can see a fact is decided before an agent is allowed to read widely. And writeback is earned. Routine steward updates can write themselves once they are proven. Claims, pricing, positioning, and roadmap facts go through a person, with no end date on that rule. The place the team already works, and any signal from outside the company, come after this core is solid. A new interface on top of an uncited store gives you confident wrong answers, faster.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">Earned</span><strong>Routine updates</strong><span>Status, dates, and what moved. Steward writes them once proven.</span></div>
<div class="jn-window-end"><span class="jn-label">A person</span><strong>The facts that bind</strong><span>Claims, pricing, positioning, roadmap. No end date.</span></div>
</div>

Deploy in the same spirit. Start on-demand, the kind that runs when a person asks. Let an always-on agent earn that status. A lane that only watches may flag. It does not fix, block, or decide until it has a record that justifies more.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">On demand</span><span class="jn-pillars-q">Runs when a person asks. This is where a lane starts.</span></li>
<li><span class="jn-pillars-name">Always on</span><span class="jn-pillars-q">Earns it. A watcher may flag. It does not decide.</span></li>
</ul>

If the review pile grows faster than the people who approve it, narrow what the agents are allowed to start. Do not add agents to outrun the approvers. The specialists are the constraint.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="6" y="4" width="12" height="16" rx="1"/><path class="is-mark" d="M9 12h6"/></svg>What stops an agent</h3>

Four stops, and governance is what enforces them.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Tier</span></li>
<li><span class="jn-label">2</span><span>Citation</span></li>
<li><span class="jn-label">3</span><span>Never-do</span></li>
<li class="is-now"><span class="jn-label">4</span><span>The record</span></li>
</ol>

The tier. Locked copy is not rewritten. Flexed copy waits for a person. An agent does not introduce a value proposition that was not in the brief.

The citation. Every fact carries where it came from, and a date. An inferred fact is not a customer-stated fact. An outdated fact is not settled. Public information is labeled public.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Stated</span><span class="jn-pillars-q">A customer said it, or a person approved it.</span></li>
<li><span class="jn-pillars-name">Derived</span><span class="jn-pillars-q">It came from a report or from analytics. Say so.</span></li>
<li><span class="jn-pillars-name">Inferred</span><span class="jn-pillars-q">The agent concluded it. It is not a fact yet.</span></li>
<li><span class="jn-pillars-name">Stale</span><span class="jn-pillars-q">Outdated or unverified. Do not ship it as settled.</span></li>
</ul>

The never-do list. Claims, pricing, positioning, and roadmap facts stay with a person. So does creating the work in the system before someone says yes. So does treating a single inferred signal as a reason to open a task.

The record. Nothing on the always-on side, and no unattended write, until the lane has been right often enough that a person will sign for the pattern.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="8" r="3"/><path class="is-mark" d="M6 19c1.5-3 3.5-4.5 6-4.5S16.5 16 18 19"/></svg>What still belongs to a person</h3>

Strategy. Whether a claim is true. The customer conversation. The creative idea. The call on what to stop funding. The review of what the agent drafted. The first offer that has to be useful, with a defined output and a cap on expert time. An agent can draft that offer. A person is accountable for it.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">A person</span><span class="jn-pillars-q">Strategy, the claim, the customer, the idea, what to stop, and the approval.</span></li>
<li><span class="jn-pillars-name">An agent</span><span class="jn-pillars-q">The draft, the routine record, and the report. The offer still has an owner.</span></li>
</ul>

Approval is a skill. The person catching a wrong claim, a stale number, or a promise the product cannot keep is doing the job. A team that treats that review as a rubber stamp has agents without oversight.

## The numbers

I am not tying a result to this system. Evaluation is the last move on purpose, and it is not measured yet. The pipeline-per-program-dollar result has its own guide, and I am not borrowing it here.

When evaluation exists, four watches belong on it. Whether the answer was accurate. Whether the citation was the right kind. How often a fact was stale. And time returned to strategy, which is the point of taking the repetitive work off people. There is no baseline and no period for any of them yet.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Accuracy</span><span class="jn-pillars-q">Was the answer right. Not measured yet.</span></li>
<li><span class="jn-pillars-name">Citation</span><span class="jn-pillars-q">Was the source the right kind. Not measured yet.</span></li>
<li><span class="jn-pillars-name">Stale facts</span><span class="jn-pillars-q">How often a fact was old. Not measured yet.</span></li>
<li><span class="jn-pillars-name">Time returned</span><span class="jn-pillars-q">Repetitive work handed back to strategy. Not measured yet.</span></li>
</ul>

## What you can take with you

The failure mode is an unmarked fact. An inference, or an outdated line, gets treated as settled because nothing said where it came from. A person catches it at the end. That is the expensive place to catch it. Citation exists so the catch happens at the gate, while the draft is still a draft.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">At the gate</span><strong>Citation</strong><span>Caught while the draft is still a draft.</span></div>
<div class="jn-window-end"><span class="jn-label">Too late</span><strong>A person, at the end</strong><span>The expensive place to catch it.</span></div>
</div>

What I would change is the order. Write the operating model before the first prompt. Put the five lanes on it, each with an approver and a line on the never-do list. Build the schema and the citation before an agent is allowed to write. If the review pile grows, cut the scope of what the agents start.

<ol class="jn-stages is-four">
<li class="is-now"><span class="jn-label">1</span><span>Operating model</span></li>
<li><span class="jn-label">2</span><span>Five lanes</span></li>
<li><span class="jn-label">3</span><span>Schema and citation</span></li>
<li><span class="jn-label">4</span><span>Cut the scope</span></li>
</ol>

Here is the checklist.

<ul class="jn-check">
<li><label><input type="checkbox" /><span>Write the operating model first. An agent runs a stage that already has an artifact and a gate.</span></label></li>
<li><label><input type="checkbox" /><span>Give each agent one lane: intake, decomposition, steward, rollup, or governance. Name who approves it.</span></label></li>
<li><label><input type="checkbox" /><span>Start on-demand. A steward writes routine updates only after it has a record.</span></label></li>
<li><label><input type="checkbox" /><span>Keep claims, pricing, positioning, and roadmap facts with a person, with no end date.</span></label></li>
<li><label><input type="checkbox" /><span>Mark where every fact came from. An inferred fact is not a customer-stated fact.</span></label></li>
</ul>

An agent that runs a stage you already designed, and hands the work back with an artifact and an approver, is a good colleague. An agent that quietly ships its own work is a liability, however good the draft looks.]]></content:encoded>
  </item>
<item>
    <title>Brand integration after an acquisition</title>
    <link>https://www.jeffnolan.com/field-guides/brand-integration-after-an-acquisition/</link>
    <guid>https://www.jeffnolan.com/field-guides/brand-integration-after-an-acquisition/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>What to keep, what to redirect, and what happens to pipeline while two brands overlap, worked through with a made-up parent and a made-up acquisition.</description>
    <content:encoded><![CDATA[## The problem

When an acquisition closes, the announcement is the easy part. The hard part is the next year. The acquired company still has a website, a contact database, a sales team, and a pipeline. The parent has its own versions of all four. For a while, both run.

Most integration plans are written by legal, finance, and product. Marketing gets a list of dates and a logo file. Meanwhile, customers on both sides are still visiting two sites, receiving two sets of email, and talking to two sales teams who may not know what the other is saying.

The work in front of marketing is not mainly a design project. It is an operating problem. What stays? What redirects? Where does a lead go when it arrives at the old address? Who owns the answer when sales asks which brand to use in a proposal? If nobody answers those questions in writing, they get answered a hundred times a day by whoever is closest, and the answers will not match.

To keep this concrete, I'm going to walk through it with a made-up pair of companies. Alder Systems is the parent. It sells security software to mid-size businesses. Fernwood Labs is a smaller company it just acquired, with a loyal base of technical users and a trial-led sales motion. Neither company is real, and nothing below is a result. It is an example of the decisions, in the order I would make them.

## The system

A sequence of decisions, in this order.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Brand structure</span></li>
<li><span class="jn-label">2</span><span>Asset piles</span></li>
<li><span class="jn-label">3</span><span>Lead routing</span></li>
<li class="is-now"><span class="jn-label">4</span><span>An end date</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="4" y="6" width="7" height="12" rx="1"/><rect class="is-mark" x="13" y="6" width="7" height="12" rx="1"/></svg>What stays</h3>

Start with the brand structure. There are only a few real options. A branded house: the acquired name retires and the parent absorbs it. A house of brands: the acquired name stays as its own brand, with or without a line that says it is part of the parent. Or the two merge into something new. Each has a cost. Retiring a brand people trust throws away equity. Keeping two brands doubles the work of every launch.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="7" y="5" width="10" height="14" rx="1"/><path class="is-mark" d="M7 9h10"/></svg><span><span class="jn-label">Branded house</span>The acquired name retires. The parent absorbs it.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="4" y="6" width="7" height="12" rx="1"/><rect class="is-mark" x="13" y="6" width="7" height="12" rx="1"/></svg><span><span class="jn-label">House of brands</span>The acquired name stays, with or without an endorsement.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 8h5M5 16h5"/><path class="is-mark" d="M14 12h5"/></svg><span><span class="jn-label">Something new</span>The two names merge.</span></li>
</ol>

The choice depends on three things: how much equity the acquired name carries with its buyers, how much the buyers overlap with the parent's, and whether the products will converge or stay apart.

In our example, Fernwood has real standing with the engineers who use it every day. Alder's buyers are mostly the managers who approve spend. The overlap is small, and the two products will stay separate for at least a year. So Alder chooses a house of brands, and endorses Fernwood. Fernwood keeps its name and its own site, with a line that says "a part of Alder Systems." The name that retires later, if it does, retires when the products converge, not on day one.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">Now</span><strong>House of brands</strong><span>Fernwood keeps its name. The line is "a part of Alder Systems."</span></div>
<div class="jn-window-end"><span class="jn-label">Later</span><strong>When products converge</strong><span>The name retires then, not on day one.</span></div>
</div>

Make the call early, and make it in writing. Every other decision, from the website to the sales deck, depends on it. An open brand question is the most expensive kind of open question, because pages, emails, and decks get built on assumptions that will later need to be redone.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h12"/><path class="is-mark" d="M6 12h12"/><path d="M6 17h12"/></svg>What moves, and what waits</h3>

Sort every asset into three piles. Move now. Move later. Stay until a lawyer says otherwise.

The assets are the website, the domains, the contact database, the marketing automation, the analytics, the social accounts, the customer references, and the content library. For each one, name an owner, a target date, and what depends on it.

At Alder and Fernwood, the pile sorts like this. Move now: the analytics tags, so both sites report into one view, and the social account handles, which only need a bio change. Move later: the contact database, which waits for a data protection review, and the marketing automation, which waits until the lead-routing rule has run for a month. Stay until legal clears it: Fernwood's customer reference list, because some of the agreements restrict how a name can be used after a change of control.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 12h10"/><path class="is-mark" d="M12 8l4 4-4 4"/></svg><span><span class="jn-label">Now</span>Analytics tags and social handles.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M12 8v5l3 2"/></svg><span><span class="jn-label">Later</span>The contact database, then the marketing automation.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="6" y="4" width="12" height="16" rx="1"/><path class="is-mark" d="M9 9h6"/></svg><span><span class="jn-label">Legal</span>Customer references stay until a lawyer clears them.</span></li>
</ol>

Some assets will have to wait. Regulatory review, data protection rules, or contracts may limit what you can touch and when. Know which assets are in that pile before you promise a date.

Redirects deserve their own line. Every old page that gets retired needs a place to send people, and the map has to exist before the page goes away. Search engines, customers, and your own sales team all follow the old links for a long time. In the example, Fernwood's pricing page is retired and replaced by a combined page on Alder's site. The redirect goes live the same day, and the old URL is checked weekly for the first quarter.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">Same day</span><strong>Redirect</strong><span>The old pricing page goes to the combined page on Alder's site.</span></div>
<div class="jn-window-end"><span class="jn-label">First quarter</span><strong>Check the old URL</strong><span>Weekly.</span></div>
</div>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="7" cy="8" r="2"/><circle cx="17" cy="8" r="2"/><circle class="is-mark" cx="12" cy="16" r="2"/><path d="M9 9l2 5M15 9l-2 5"/></svg>What happens to pipeline during the overlap</h3>

This is where the damage happens, and it is mostly mundane.

Leads arrive at one system and get worked in another. Contacts exist in two databases with two sets of permissions. A form on the old site feeds a list that nobody on the new team is watching. A trial that stays on old infrastructure produces leads with the wrong source, so attribution is wrong from the first touch.

Here is how it plays out in the example. Fernwood's free trial runs on Fernwood's servers. A person signs up, the lead lands in Fernwood's database, and Alder's sales team never sees it. Meanwhile an Alder rep gets a form fill from the same company and calls them cold. Two teams, one account, no knowledge of each other.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Fernwood</span><span class="jn-pillars-q">The trial lead lands in Fernwood's database.</span></li>
<li><span class="jn-pillars-name">Alder</span><span class="jn-pillars-q">A form fill from the same company. The rep calls cold.</span></li>
</ul>

Write the lead-routing rule for the overlap before the close, not after the first complaint. Where does each type of lead go, who works it, and how fast? In our example the rule is short. Trial sign-ups route to the Fernwood team within one business day. Any account that also appears in Alder's database gets flagged and shared, so the first rep to reach out knows about the other. One named person owns the rule and reviews exceptions every week.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 12h10"/><path class="is-mark" d="M12 8l4 4-4 4"/></svg><span><span class="jn-label">Route</span>Trial sign-ups go to the Fernwood team within one business day.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h5M13 7h5"/><path class="is-mark" d="M8 12h8"/></svg><span><span class="jn-label">Flag</span>An account in both databases is shared before the first call.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="9" r="3"/><path class="is-mark" d="M6 19c1.5-3 4-4 6-4s4.5 1 6 4"/></svg><span><span class="jn-label">Owner</span>One person reviews the exceptions every week.</span></li>
</ol>

Check where every form, trial, and domain lives, because that is where leads disappear and where the source gets lost.

Salespeople on both sides also need a short answer to the question customers will ask: what changes for me? Give them one paragraph and keep it current.

## The numbers

Every figure in this guide is made up, because the companies are. I am not borrowing a real result and I am not implying one. The point of a number here is to show you what to track.

The first number I would pick is days from close to a single lead-routing rule in force. It is small, it is specific, and it is the first thing that tells you whether the overlap is under control. In the Alder example, call it 45 days. That is a model figure, flagged as illustrative, and it is not a benchmark.

Pick the number before the close and write it down.

## What you can take with you

Ten things go wrong. The brand call is the serious one. The next two are the decisions that get made too late. The rest are how the overlap does the damage.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">1 · Serious</span><strong>The brand call flips</strong><span>House of brands, then a branded house, after work has started.</span></div>
<div class="jn-window-end"><span class="jn-label">Then</span><strong>Build it again</strong><span>The site, the contacts, and the campaigns followed the last answer.</span></div>
</div>

The brand structure is the serious error. Alder flips between a house of brands and a branded house after work has already started. The site, the contacts, and the campaigns were built on the last version of the answer, and they have to be built again.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">2</span><span class="jn-pillars-name">Trial</span><span class="jn-pillars-q">The move onto the parent system comes late, and the brand stays confusing.</span></li>
<li><span class="jn-pillars-n">3</span><span class="jn-pillars-name">Routing</span><span class="jn-pillars-q">The rule and the integrated system arrive after the start.</span></li>
</ul>

The next is moving the trial onto the parent system. In the example, Fernwood's trial keeps running on Fernwood's servers while Alder waits to migrate it. The wait costs time. It also perpetuates the confusion, for the team and for customers, about which brand they are dealing with. That confusion lasts as long as the trial sits on the old infrastructure.

Then lead routing. The rule, and the integrated system that runs it, belong at the beginning of the integration. In the example they arrive later. Until they do, a trial sign-up lands in Fernwood's database and an Alder rep calls the same company cold.

<ol class="jn-tiers is-plain">
<li><span class="jn-label">4 · One account</span><span>Two teams work it, and neither knows about the other.</span></li>
<li><span class="jn-label">5 · Source</span><span>Forms, trials, and domains stay put, so the source on the lead is wrong.</span></li>
<li><span class="jn-label">6 · Order</span><span>The database moves before a review, or the automation moves before the rule has run.</span></li>
<li><span class="jn-label">7 · Redirects</span><span>A page retires and the old link goes nowhere.</span></li>
<li><span class="jn-label">8 · The question</span><span>Customers ask what changes, and the two sales teams give two answers.</span></li>
<li><span class="jn-label">9 · References</span><span>A customer name gets used after a change of control, and the agreement does not allow it.</span></li>
<li><span class="jn-label">10 · No end</span><span>The overlap never closes, and the temporary state becomes the way the company runs.</span></li>
</ol>

What I would change is the order. Settle the brand structure first, and do not flip between a house of brands and a branded house. Write the asset list before the close, including when the trial infrastructure moves. Put the lead-routing rule and the integrated routing system in at the beginning. Name an owner for the overlap, and put an end date on it.

<ol class="jn-stages">
<li class="is-now"><span class="jn-label">1</span><span>Brand, and do not flip</span></li>
<li><span class="jn-label">2</span><span>Asset list</span></li>
<li><span class="jn-label">3</span><span>Trial move</span></li>
<li><span class="jn-label">4</span><span>Routing system</span></li>
<li><span class="jn-label">5</span><span>Owner and end date</span></li>
</ol>

Here is the checklist.

<ul class="jn-check">
<li><label><input type="checkbox" /><span>Name the brand structure before you touch the website: house of brands or branded house, which brand stays, which is endorsed, which retires. Do not flip the call.</span></label></li>
<li><label><input type="checkbox" /><span>List every asset in three piles: moves now, moves later, and stays until legal clears it.</span></label></li>
<li><label><input type="checkbox" /><span>Write the lead-routing rule for the overlap, deploy the integrated routing system at the beginning, and name the person who owns it.</span></label></li>
<li><label><input type="checkbox" /><span>Check where forms, trials, and domains live, because that is where attribution breaks.</span></label></li>
<li><label><input type="checkbox" /><span>Put an end date on the overlap, and review it on the calendar.</span></label></li>
</ul>

An acquisition is not integrated when the logo changes. It is integrated when a lead from either side lands in the same place and gets the same follow-up.]]></content:encoded>
  </item>
<item>
    <title>Building a digital marketing engine from scratch</title>
    <link>https://www.jeffnolan.com/field-guides/digital-engine-from-scratch/</link>
    <guid>https://www.jeffnolan.com/field-guides/digital-engine-from-scratch/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>The order I would stand up a digital marketing system when there isn't one: what to build first, what to refuse to build yet, and the first number that shows the engine is real.</description>
    <content:encoded><![CDATA[## The problem

The common way to build a marketing engine is to buy the stack first and figure out the work later. A CRM. An automation platform. A dashboard tool. Some AI on top. Each one makes sense on its own. Together they make a mess that nobody can describe in one sentence.

That is what building without an order looks like. Every piece works. The whole thing does not. And the cost shows up late, as an argument about whose number is right, or as a project to tear down what was just built before anyone can automate it.

The harder case is not an empty room. On day one there was a collection of tools and applications, and no consistent process. The campaign system was disconnected from regional field marketing. Every turn of the campaign cycle was invented again. Nothing got done quickly. The results were disconnected from actual performance, because attribution was inconsistent.

This guide is the order I used to build the engine in my current role. It is a sequence, not a tool list.

## The system

Build the operating system first. Every campaign needs a roadmap it follows from the idea to the review. Then build the team structure and a DACI to manage the workflow. Only then build the systems that support the workflow. The agentic strategy comes last. The goal is to widen and deepen the signal so you can microtarget tiny audiences, and to cut the time to launch a new campaign to minutes, not weeks or months.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Operating system</span></li>
<li><span class="jn-label">2</span><span>Team and DACI</span></li>
<li><span class="jn-label">3</span><span>Systems</span></li>
<li class="is-now"><span class="jn-label">4</span><span>Agentic, last</span></li>
</ol>

A separate content pipeline, on its own agentic process, lets the demand teams pick work off the shelf. It is the same move as shopping for groceries to cook a recipe you just found.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">Pipeline</span><strong>Off the shelf</strong><span>Finished pieces, from their own agentic process.</span></div>
<div class="jn-window-end"><span class="jn-label">Campaign</span><strong>The recipe</strong><span>Demand picks what this campaign needs.</span></div>
</div>

Five pieces sit inside that order. Each one makes the next one safe.

<ol class="jn-stages">
<li><span class="jn-label">1</span><span>Cadence</span></li>
<li><span class="jn-label">2</span><span>Definitions</span></li>
<li><span class="jn-label">3</span><span>Data map</span></li>
<li><span class="jn-label">4</span><span>Automations</span></li>
<li class="is-now"><span class="jn-label">5</span><span>Agents</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="5" y="6" width="14" height="13" rx="1.5"/><path class="is-mark" d="M5 10h14"/><path d="M9 4v4M15 4v4"/></svg>1. The cadence</h3>

Build the meeting before the machine. A standing forum where the people who plan campaigns and the people who run them in the field sit down together, on a fixed rhythm, with a short agenda. It gets what the field knows into a plan before the plan is written.

Pair it with a gate and an artifact at each handoff. No artifact, no handoff. When work moves from one team to the next, something written moves with it. None of this needs software. It needs a calendar and a rule.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 6h10"/><path class="is-mark" d="M7 12h10"/><path d="M7 18h6"/></svg>2. Definitions</h3>

Before a single dashboard, agree what the words mean. What is a lead? What is a qualified lead? What is a source? What is a trial, if you have trials? Write each one down, name one source of truth, and get the owners to agree.

Do it first because it is cheapest first. On day one, nobody has a number to defend. Six months in, every definition has a person whose results depend on it, and changing one becomes a negotiation.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="7" cy="8" r="2"/><circle cx="17" cy="8" r="2"/><circle class="is-mark" cx="12" cy="16" r="2"/><path d="M9 9l2 5M15 9l-2 5"/></svg>3. The data map</h3>

Next, map where the truth lives. The CRM, the warehouse, the project board, the call transcripts, the briefs, the analytics. Resolve identity across them, so the same account is the same account everywhere.

Then apply one hard rule: every fact has one primary home. The schema comes before ingestion, not after. Structure does not fix itself because something is powered by AI. If you load disorder into a smarter system, you get smarter disorder.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 8h8a3 3 0 0 1 0 6H9"/><path class="is-mark" d="M9 11l-3 3 3 3"/></svg>4. The automations</h3>

Now take the repetitive work off people. Routing, reminders, status updates, first drafts. These are deterministic, and they should be boring. They free people to spend their time on strategy, judgment, customers, and creative, which is where the engine actually earns its keep. Do this only after steps one through three, because automating a process with no agreed definitions just produces wrong answers faster.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="8" cy="8" r="2.5"/><path class="is-mark" d="M10.5 10.5L16 16"/><circle cx="17.5" cy="17.5" r="2"/></svg>5. Agents, last</h3>

Agents come last, and on a short leash. Start with on-demand ones, the kind that run when a person asks. Let an always-on agent earn its place. Anything that touches a claim, a price, or a customer quote goes through a person, with no end date on that rule.

## What to refuse to build yet

The refusals matter as much as the sequence.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">No chat layer</span><span class="jn-pillars-q">Not on top of disconnected data.</span></li>
<li><span class="jn-pillars-name">No fine attribution</span><span class="jn-pillars-q">Not yet. Confirm the contribution first.</span></li>
<li><span class="jn-pillars-name">No tool for a signal</span><span class="jn-pillars-q">Only after a repeated, costly gap.</span></li>
<li><span class="jn-pillars-name">No orphan build</span><span class="jn-pillars-q">It has to serve a job someone needs done.</span></li>
</ul>

Do not put a chat interface on top of disconnected data. It will give you confident wrong answers, faster.

Do not chase granular attribution early. Confirming that marketing contributes to good outcomes is more useful than perfecting the credit for each touch, especially when part of your business runs through partners who report late.

Do not buy a tool because a signal exists. Add one only after the work shows a repeated, costly gap.

And do not build anything that does not trace back to a job someone needs done. Write the list of jobs first. Campaign retros. Consistent positioning. Proof points your sales team can find. If a piece of the build does not serve one of those, it is scope creep.

## The numbers

There is no cleared percentage for this guide. Every number here needs a period and a baseline, or it stays open. These two do not have one yet.

Two numbers to focus on. Engagement across the target market populations, and coverage in the total database. Open rates and click rates are the usual metrics, and they are not enough on their own. What those targets do across the digital assets is what drives the outcome. The engagement metrics are the necessary conditions for a demand funnel. The output of the campaigns is a lead-gen number. That is where the rubber hits the pavement.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Engagement</span><span class="jn-pillars-q">Across the target populations. Open and click are the start.</span></li>
<li><span class="jn-pillars-name">Coverage</span><span class="jn-pillars-q">In the total database. The output is the lead-gen number.</span></li>
</ul>

## What you can take with you

Start with what failed. Communication failed, repeatedly, because teams were not talking to each other through the process. A heads-down, get-the-work-done attitude dooms the collective effort when each team's work has to be coordinated with the others. We also failed to standardize attribution and campaign membership across campaigns. And we failed to run more campaigns in parallel. We did not embrace tiny audiences, and the effort to get a campaign to execution over-relied on people.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 8h6M5 12h4"/><path class="is-mark" d="M13 10h6M13 14h4"/></svg><span><span class="jn-label">Talk</span>Teams were not talking through the process</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h12M6 12h12"/><path class="is-mark" d="M6 17h8"/></svg><span><span class="jn-label">Standard</span>Attribution and campaign membership</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="8" cy="12" r="2"/><circle cx="16" cy="8" r="2"/><circle class="is-mark" cx="16" cy="16" r="2"/></svg><span><span class="jn-label">Parallel</span>Tiny audiences, not only human effort</span></li>
</ol>

The order that held was the operating system, then the team and the DACI, then the systems, and the agentic work last. The content pipeline is its own process, so a demand team can take a finished piece off the shelf instead of starting from nothing.

Here is the checklist.

<ul class="jn-check">
<li><label><input type="checkbox" /><span>Start with a standing meeting and a gate artifact, not a tool.</span></label></li>
<li><label><input type="checkbox" /><span>Agree one definition and one source of truth for every number before you build a dashboard.</span></label></li>
<li><label><input type="checkbox" /><span>Give every fact one home before you load anything into a shared store.</span></label></li>
<li><label><input type="checkbox" /><span>Add a tool only after the work shows a repeated, costly gap.</span></label></li>
<li><label><input type="checkbox" /><span>Keep agents on a short leash. On-demand first. Always-on only once earned.</span></label></li>
</ul>

An engine that is built in order is easy to explain in one sentence. If you cannot explain yours, that is the first thing to fix.]]></content:encoded>
  </item>
<item>
    <title>The growth engineer's stack</title>
    <link>https://www.jeffnolan.com/field-guides/growth-engineers-stack/</link>
    <guid>https://www.jeffnolan.com/field-guides/growth-engineers-stack/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>A stack of tools is not an agent system. Orchestration reads one brain of context, skills, and outcomes, and the next run starts from what the last one wrote.</description>
    <content:encoded><![CDATA[It is easy to draw this as a marketing stack. Enrichment, routing, attribution, search, and an agent named on each layer. A team with no agents could run that chain. A journey tool already does. It fires the next step when a field changes. It does not choose a procedure. It does not share a memory. It does not get better because someone corrected the last run.

The agent was a label. The system was missing.

## What is actually an agent system

Three files, and a loop that uses them. The files are not tools in a catalog. Each one has a different job, and mixing them up is how the stack comes back.

<ol class="jn-steps">
<li><span class="jn-label">Context file</span><span>A person writes it. Every run loads it. It holds what does not change with the task.</span></li>
<li><span class="jn-label">Skill</span><span>The procedure for a class of work. The loop sees the name. It loads the file only when the job matches.</span></li>
<li class="is-now"><span class="jn-label">The brain</span><span>What is allowed to survive the run. The next run is different only because this one was written down.</span></li>
</ol>

A context file is standing orders. The capability the play is about. The definition of a source. The messaging tier. The list of things an agent must never write. Who holds the gate. If it is not in the file, the run does not have it. A wiki nobody loads is not a context file. A slide deck is not one either.

A skill is how a class of work is done. Rank this signal. Draft inside this tier. Stamp a source from the record of that moment. Write a fact back with a citation, or refuse to write it. The loop can see every skill by name. It pulls the full procedure only for the job in front of it. A prompt you paste once is not a skill. The next account will not find it.

The brain is the memory. Cited facts. A play that was retired. A correction a person made. The outcome of the last run. The model does not remember any of that. The brain does. Enrichment, routing, and search can be skills. They are not the system. If the only records in the brain are products, the loop will keep proposing the next product.

Start from the capability. A capability is what the customer needs and does not have yet. The product is what you sell once that is clear. The context file says which capability a play is for. Orchestration matches a signal to that record. It does not match to the catalog.

## How the agents touch the brain

The five lanes still do the work. Intake ranks. Decomposition drafts. The steward maintains the record. Rollup reads the outcome. Governance stops the others and does not ship. Orchestration is not a sixth marketer. It is the loop that decides which lane runs, which skill that lane loads, and what it is allowed to read.

They do not pass a spreadsheet to each other. They read the same brain. Only the steward writes back, and only a fact it can cite. Governance can stop the write. The dashed path is the next run. It starts from what was written, not from a blank prompt.

<figure class="jn-diagram">
<svg viewBox="0 0 900 580" role="img" aria-labelledby="brain-diagram-title brain-diagram-desc">
<title id="brain-diagram-title">Agents reading and writing one brain</title>
<desc id="brain-diagram-desc">A context file loads on every run. A skill loads only when the job matches. Orchestration assembles both and reads the brain. Intake, decomposition, the steward, rollup, and governance all read the brain. The steward writes cited facts back. Governance can stop that write. The next run reads what was written.</desc>
<g>
<line class="jn-dg-grid" x1="24" y1="0" x2="24" y2="580"></line>
<line class="jn-dg-grid" x1="120" y1="0" x2="120" y2="580"></line>
<line class="jn-dg-grid" x1="216" y1="0" x2="216" y2="580"></line>
<line class="jn-dg-grid" x1="312" y1="0" x2="312" y2="580"></line>
<line class="jn-dg-grid" x1="408" y1="0" x2="408" y2="580"></line>
<line class="jn-dg-grid" x1="504" y1="0" x2="504" y2="580"></line>
<line class="jn-dg-grid" x1="600" y1="0" x2="600" y2="580"></line>
<line class="jn-dg-grid" x1="696" y1="0" x2="696" y2="580"></line>
<line class="jn-dg-grid" x1="792" y1="0" x2="792" y2="580"></line>
<line class="jn-dg-grid" x1="0" y1="24" x2="900" y2="24"></line>
<line class="jn-dg-grid" x1="0" y1="120" x2="900" y2="120"></line>
<line class="jn-dg-grid" x1="0" y1="216" x2="900" y2="216"></line>
<line class="jn-dg-grid" x1="0" y1="312" x2="900" y2="312"></line>
<line class="jn-dg-grid" x1="0" y1="408" x2="900" y2="408"></line>
</g>
<path class="jn-dg-edge" d="M186 96 L330 128"></path>
<path class="jn-dg-arrow" d="M321 120 L330 128 L318 132 Z"></path>
<path class="jn-dg-edge" d="M714 96 L570 128"></path>
<path class="jn-dg-arrow" d="M579 120 L570 128 L582 132 Z"></path>
<path class="jn-dg-edge" d="M450 204 V232"></path>
<path class="jn-dg-arrow" d="M445 232 L450 240 L455 232 Z"></path>
<path class="jn-dg-edge" d="M104 332 V380"></path>
<path class="jn-dg-arrow" d="M99 380 L104 388 L109 380 Z"></path>
<path class="jn-dg-edge" d="M277 332 V380"></path>
<path class="jn-dg-arrow" d="M272 380 L277 388 L282 380 Z"></path>
<path class="jn-dg-edge" d="M450 332 V380"></path>
<path class="jn-dg-arrow" d="M445 380 L450 388 L455 380 Z"></path>
<path class="jn-dg-edge" d="M623 332 V380"></path>
<path class="jn-dg-arrow" d="M618 380 L623 388 L628 380 Z"></path>
<path class="jn-dg-edge" d="M796 332 V380"></path>
<path class="jn-dg-arrow" d="M791 380 L796 388 L801 380 Z"></path>
<path class="jn-dg-loop" d="M450 488 V540 H12 V292 H16"></path>
<path class="jn-dg-pulse" d="M450 488 V540 H12 V292 H16"></path>
<path class="jn-dg-arrow" d="M16 287 L24 292 L16 297 Z"></path>
<text class="jn-dg-edge-label" x="458" y="226">ASSEMBLES</text>
<text class="jn-dg-edge-label" x="36" y="566">STEWARD WRITEBACK · THE NEXT RUN READS IT</text>
<g transform="translate(36 20)">
<rect class="jn-dg-node" width="300" height="76" rx="8"></rect>
<text class="jn-dg-kicker" x="16" y="22">CONTEXT FILE</text>
<text class="jn-dg-title" x="16" y="44">Context</text>
<text class="jn-dg-sub" x="16" y="62">Rules a person wrote. Loaded every run.</text>
</g>
<g transform="translate(564 20)">
<rect class="jn-dg-node" width="300" height="76" rx="8"></rect>
<text class="jn-dg-kicker" x="16" y="22">SKILL</text>
<text class="jn-dg-title" x="16" y="44">Skill</text>
<text class="jn-dg-sub" x="16" y="62">The procedure. Loaded only on a match.</text>
</g>
<g transform="translate(250 128)">
<rect class="jn-dg-node" width="400" height="76" rx="8"></rect>
<text class="jn-dg-kicker" x="16" y="22">THE LOOP</text>
<text class="jn-dg-title" x="16" y="44">Orchestration</text>
<text class="jn-dg-sub" x="16" y="62">Picks the skill, the agent, and the order.</text>
</g>
<g transform="translate(24 240)">
<rect class="jn-dg-out" width="852" height="92" rx="8"></rect>
<text class="jn-dg-out-k" x="20" y="26">MEMORY</text>
<text class="jn-dg-out-t" x="20" y="52">The brain</text>
<text class="jn-dg-out-s" x="20" y="74">Cited facts, retired plays, and the last correction. Every agent reads it.</text>
</g>
<g transform="translate(24 388)">
<rect class="jn-dg-node" width="160" height="96" rx="8"></rect>
<text class="jn-dg-kicker" x="14" y="22">01</text>
<text class="jn-dg-title" x="14" y="46">Intake</text>
<text class="jn-dg-sub" x="14" y="68">Ranks the signal.</text>
</g>
<g transform="translate(197 388)">
<rect class="jn-dg-node" width="160" height="96" rx="8"></rect>
<text class="jn-dg-kicker" x="14" y="22">02</text>
<text class="jn-dg-title" x="14" y="46">Decomposition</text>
<text class="jn-dg-sub" x="14" y="68">Drafts the work.</text>
</g>
<g transform="translate(370 388)">
<rect class="jn-dg-node" width="160" height="96" rx="8"></rect>
<text class="jn-dg-kicker" x="14" y="22">03</text>
<text class="jn-dg-title" x="14" y="46">Steward</text>
<text class="jn-dg-sub" x="14" y="68">Writes the fact.</text>
</g>
<g transform="translate(543 388)">
<rect class="jn-dg-node" width="160" height="96" rx="8"></rect>
<text class="jn-dg-kicker" x="14" y="22">04</text>
<text class="jn-dg-title" x="14" y="46">Rollup</text>
<text class="jn-dg-sub" x="14" y="68">Reads the outcome.</text>
</g>
<g transform="translate(716 388)">
<rect class="jn-dg-node" width="160" height="96" rx="8"></rect>
<text class="jn-dg-kicker" x="14" y="22">05</text>
<text class="jn-dg-title" x="14" y="46">Governance</text>
<text class="jn-dg-sub" x="14" y="68">Stops the write.</text>
</g>
</svg>
<ol class="jn-sr">
<li>Context file: rules a person wrote, loaded every run.</li>
<li>Skill: the procedure, loaded only when the job matches.</li>
<li>Orchestration: picks the skill, the agent, and the order, then assembles what the run needs from the brain.</li>
<li>The brain: cited facts, retired plays, and the last correction. Every agent reads it.</li>
<li>Intake ranks the signal. Decomposition drafts the work. The steward writes a cited fact back. Rollup reads the outcome. Governance can stop the write.</li>
<li>The next run reads what the steward was allowed to write.</li>
</ol>
<figcaption>Orchestration loads the context file every time and one skill when the job matches. All five agents read the brain. The steward writes back. Governance can stop that write. The dashed path is the next run.</figcaption>
</figure>

## What the loop does

A campaign journey sequences messages. Orchestration sequences work against the brain. Five moves, and the last one is the point.

<ol class="jn-stages">
<li><span class="jn-label">1</span><span>Match</span></li>
<li><span class="jn-label">2</span><span>Select</span></li>
<li><span class="jn-label">3</span><span>Assemble</span></li>
<li><span class="jn-label">4</span><span>Assign</span></li>
<li class="is-now"><span class="jn-label">5</span><span>Write back</span></li>
</ol>

Match the signal to a capability already in the brain. The signal has to say where it lives, how it was detected, which capability play it triggers, and who owns the next step. If a field is blank, the loop does not start. A product name is not a match. A confirmed need can become work. A verified change gets a short look. A single inferred visit does not open a task. A high-fit account with no signal still goes to a person. The loop does not invent a play to fill a queue.

Select one skill. Do not load every procedure into the run. The context window is not the memory. If two skills could apply, a person picks. The loop does not blend them and hope.

Assemble only the context that skill needs. The capability. The tier. The cited facts. The last correction on this kind of work. A retired play comes back as a refusal, not as a draft. Standing rules come from the context file. Facts come from the brain. The procedure comes from the skill. Three different places, on purpose.

Assign one agent. Intake ranks. Decomposition drafts inside the tier the context file names. The handoff is a write to the brain, not a side channel between agents. If an agent keeps a private copy, the next run will not see it, and the private copy will be wrong.

Write back, or write nothing. The steward may record a fact it can cite, with the kind of source and a date. Customer-stated, sales-reported, approved, analytics-derived, inferred, outdated, unverified. Those are not the same fact. Governance blocks a write the context file forbids. Claims, pricing, positioning, and roadmap facts stay with a person, with no end date. So does creating the work before someone says yes. A person accepts any change to a skill or to the context file. An agent may propose the edit. It does not merge it.

The context file says what a source is. Last touch, written at creation, from the record of that moment. The agent may stamp that. It may not invent one, leave one blank, or rewrite it later. Influenced is a view rollup may show. It is not sourced. The 2026 record is 100% of sourced opportunities attributed to a channel. That is the marketing-sourced population. It is not a score for the agents, and it is not evidence the brain got smarter.

## Where the next run gets better

I am not tying a rate to this. There is no baseline yet for whether a corrected mistake stays corrected.

The mechanism is the write. A person corrects a draft. That correction is stored as a cited fact, or the play is marked retired. The next orchestration reads it before it selects a skill. The skill file did not get smarter. The brain did. If the correction never lands, the agent makes the same mistake on the next account. That is a writeback failure, not a model failure.

<ol class="jn-steps">
<li><span class="jn-label">Drift</span><span>A fact stays after it is stale. The next run treats it as current.</span></li>
<li><span class="jn-label">Blur</span><span>One account's correction becomes a rule for every account.</span></li>
<li><span class="jn-label">Pollution</span><span>An agent writes what it cannot cite. The next run treats it as settled.</span></li>
</ol>

Governance is the lane that stops those writes. A watcher may flag a stale fact. It does not fix, block, or decide until it has a record of being right. Routine writeback is earned the same way. On demand first. A standing write only after a person will sign for the pattern.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">Until the files exist</span><strong>By hand</strong><span>Match, select, and write back yourself. The loop is the behavior, not a platform.</span></div>
<div class="jn-window-end"><span class="jn-label">Not yet</span><strong>Another tool</strong><span>A tool that promises the memory, before a person has corrected a run and seen it stick.</span></div>
</div>

## What I would not call this

The failure this is written to prevent: a catalog of tools, each with its own agent, none of them reading the same brain. The work looks automated. The next run is as ignorant as the last one.

The second failure is a brain everyone can write to. Speed without a citation, and the memory rots. The third is waiting on instrumentation or shopping for a platform that claims to be the loop. Until the context file, the skill, and the writeback exist, run the handoff by hand.

Evaluation, when it exists, watches one thing this guide cares about. Whether a corrected mistake came back. Alongside it, the same watches as the agent lanes: whether the answer was right, whether the citation was the right kind, how often a fact was stale, and whether a person's time moved back to the decision. None of those have a baseline yet. I will not borrow another guide's ratio to fill the gap.

<ul class="jn-check">
<li><label><input type="checkbox"> Put the capability in the context file. The product is not the record orchestration matches on.</label></li>
<li><label><input type="checkbox"> Write the procedure as a skill the loop loads when the job matches. Do not paste a new prompt for the same job.</label></li>
<li><label><input type="checkbox"> One brain. Every agent reads it. A steward writes back only a fact it can cite, and governance can stop the write.</label></li>
<li><label><input type="checkbox"> Orchestration assigns the agent and the order. Agents do not hand work to each other on the side.</label></li>
<li><label><input type="checkbox"> Do not call the system better until a corrected mistake stays corrected. That watch has no baseline yet.</label></li>
</ul>]]></content:encoded>
  </item>
<item>
    <title>Leading a hybrid team: people and agents</title>
    <link>https://www.jeffnolan.com/field-guides/leading-a-hybrid-team/</link>
    <guid>https://www.jeffnolan.com/field-guides/leading-a-hybrid-team/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>The hard part is moving the marketers you already have. The skill can be built. Experience has to sit on the decisions and the gates.</description>
    <content:encoded><![CDATA[## The problem

When agents take on the repetitive work, a marketing team's job descriptions go stale. The campaign manager who used to spend much of the week assembling tickets and first drafts now spends it differently. The manager who used to review output now reviews output that a person did not write.

The hard part is not finding a new kind of hire. It is taking the marketing professionals you already have and moving them into this way of working. The skill set can be built. The expertise that used to set a person apart is now a commodity. What still matters is experience, and where you put it. On the decisions. On the gates. Those calls can define success or failure.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 16V8"/><path class="is-mark" d="M6 12h8l3-3"/></svg><span><span class="jn-label">Skill</span>It can be built. Do not treat the new work as a gift a few people are born with.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="6" y="6" width="12" height="12" rx="1"/><path class="is-mark" d="M9 12h6"/></svg><span><span class="jn-label">Expertise</span>The old craft is now a commodity. An agent can draft it.</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h12v10H6z"/><path class="is-mark" d="M6 12h12"/></svg><span><span class="jn-label">Experience</span>It belongs on the decision and on the gate. That is what can define the outcome.</span></li>
</ol>

I have led teams of up to 60 people over my career. This guide is about how I think about moving a team I already have, and about hiring, organizing, and developing people when agents do the repetitive work. It is a method, and I have written it so you can use it whether your team is five people or fifty.

## The system

### The lane and the number each person owns

Every person gets a lane and one number. The lane says what they own. The number says how we know it is working. Both go in writing, along with what is out of scope.

The out-of-scope list is the part people skip, and it is the part that prevents the most trouble. When two roles can both reasonably claim the same work, they will, and the work either gets done twice or not at all. Writing down what a role does not do is how you find the overlap before it becomes an argument.

The number should be one that the person can move. If it depends mostly on someone else's decisions, it is not their number. Pick the closest thing they actually control, and say what it feeds.

The role I am hiring, and running, is a growth engineer for expansion inside the existing customer base. The lane is to turn product, lifecycle, and engagement signals into qualified expansion pipeline. Expansion means a sales opportunity with a customer we already have, for a product they do not already license. The work runs continuously. It is not a campaign that starts and ends.

This role owns the play. The signal, the persona, the content inside the messaging tiers, the channel, the outcome, and the name of the person in the region who will run it. Field owns that regional execution. The growth engineer brings the play, the signal, and the assets. Field does the work in the region.

The number they own is that expansion pipeline. Not a new logo. Not retention, and not a saved renewal. If the number moves because someone else saved a customer, it is not their number.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">In the lane</span><span class="jn-pillars-q">The signal, the play, the assets, and the expansion pipeline.</span></li>
<li><span class="jn-pillars-name">Out of the lane</span><span class="jn-pillars-q">New logos, regional events and channel mix, positioning, retention, references, roadmap, and pricing.</span></li>
</ul>

A play has a signal, a persona, content inside the tiers, a channel, an outcome, and a regional owner. If it does not produce, it is retired. If the instrumentation is not ready, the work runs by hand. It does not wait.

Around each role, the structure is a hybrid. One group owns the what and the why. Another owns the how and the where. For this role, the shared accountability is the expansion pipeline. Field is accountable for the execution in the region. Whoever builds the systems the others plug into is judged on whether the engine is getting faster, cheaper, and more repeatable.

### Hire and rate for judgment

When agents draft, the scarce skill is no longer the draft. The skill of checking, of designing a play, of shutting one off, can be built. The expertise that used to be the job is now a commodity. What the tool cannot supply is experience on the decision and on the gate. Someone who catches a wrong claim, a stale number, or a promise the product cannot keep is worth more than someone who is only fast with the tools. I will take a candidate who is average with the tools and sharp on the gate over the reverse.

For hiring, that changes the interview. I want to see someone look at a draft and find what is wrong with it. Give the candidate a real draft with real mistakes in it, and watch what they catch. I will take a candidate who is average with the tools and sharp on checking over the reverse.

The open role is the growth engineer above. I am not hiring for a tool. I am hiring for someone who can say which signal deserves a play, design that play, and shut it off when it does not produce.

### What coaching changes

Before, I coached on the output. Was the brief good? Did the campaign hit target?

Now I coach on the gate. How did you decide that claim was safe? What did you change from the draft, and why? Which step did you hand to an agent, and which did you keep? The people already have the experience. The transition is teaching them to spend it on those calls, instead of on the draft an agent can now write.

Two habits help. Rate people on evidence from real work, and form your own view before you read how they rate themselves, so you are not anchored on their story. And do not rate anyone highly on a dimension without evidence you could show someone else.

Each person gets a short written plan: where they are, the one thing that would move them most, a target for the next quarter, a few named actions, someone to learn from, and a date to look again.

### What ready means

Ready is the question I most want to answer before I step back. I use a simple test. A person is ready to work without me when someone else on the team has adopted their workflow, and there is a measured result. Not when they are fast. When their work travels.

People who are ready should coach someone. That is part of the definition of ready, not a reward for it. If you can do it but cannot explain it to a colleague, you are not yet ready to be left alone with it.

## The numbers

There is no cleared headcount for this guide, and I am not claiming one. I am not giving a count of people hired, promoted, or now in senior roles.

The number on the page is the one the expansion role owns. Qualified expansion pipeline. Opportunities to existing customers for products they do not already have. I am not publishing a baseline or a target for it.

The other figure in this guide is the one in the opening, a career span. It describes the scale of teams I have led. It does not describe any one company or any one role.

## What you can take with you

The role is written so two failures do not get to settle in. A play that does not produce keeps running. And the work waits because the instrumentation is not ready. The fix is in the lane. Retire the play. Run the work by hand until the instrumentation catches up.

I also see a risk ahead for any leader doing this. If people learn later that an assessment fed a reorganization, trust drops. Tell the team up front what the results will and will not be used for, and keep to it.

What I would change is the order. Write the lane, the out-of-scope list, and the number first. That is the charter. Then hire. Then assess.

Here is the checklist.

<ul class="jn-check">
<li><label><input type="checkbox" /><span>Write each person's lane and the one number they own, and say what is out of scope.</span></label></li>
<li><label><input type="checkbox" /><span>Hire and rate for judgment and verification first, tool skill second.</span></label></li>
<li><label><input type="checkbox" /><span>Coach how a person checks agent output, not just what they ship.</span></label></li>
<li><label><input type="checkbox" /><span>Define ready in writing. Someone else adopts your workflow, with a measured result.</span></label></li>
<li><label><input type="checkbox" /><span>Tell the team up front what an assessment will and will not be used for.</span></label></li>
</ul>

A team where agents handle the repetitive work still runs on good people. It needs people who are clear on their lane, sharp on checking, and trusted to work without me in the room.]]></content:encoded>
  </item>
<item>
    <title>How microtargeting and digital campaigns drive event success</title>
    <link>https://www.jeffnolan.com/field-guides/microtargeting-drives-event-success/</link>
    <guid>https://www.jeffnolan.com/field-guides/microtargeting-drives-event-success/</guid>
    <pubDate>Wed, 04 Nov 2026 00:00:00 GMT</pubDate>
    <description>An event is the last mile. Microaudiences decide who reaches an activation, and the pipeline is won in the weeks after, when the team is already on the next thing.</description>
    <content:encoded><![CDATA[Most events are measured by what is easy to count. Badge scans. Booth visits. Sessions attended. Those numbers go up when you spend more, and they feel like progress. They do not tell you whether the right people were there.

The room fills with whoever shows up. Some are buyers. Many are not. Sales gets a stack of leads after the event, mostly cold, and learns to ignore the next stack. Marketing says the event was about relationships. Sales nods and stops answering.

The event was treated as the campaign. It is not. It is the last mile. The campaign is who you chose, how you reached them, what you offered, and what you did when they left.

## Choose who the event is for

At IACP, the job was not to fill a booth. It was to drive a selected set of people to activations. The list came first, and it was built as microaudiences, not as "public safety" in one pile.

<ol class="jn-steps">
<li><span class="jn-label">Agency</span><span>City, county, and state. Those are different accounts, with different budgets and different buying paths.</span></li>
<li class="is-now"><span class="jn-label">Role</span><span>Command staff, elected officials, and the people inside the account who influence the buy. They do not attend for the same reason.</span></li>
<li><span class="jn-label">Depth</span><span>Capture the account. Then another buying center. Then a use case they do not have yet.</span></li>
</ol>

In a government motion the set of accounts is finite. There are a fixed number of law enforcement agencies in a country. You are not hunting an endless market. You are trying to win an account, grow inside it across buying centers, and go deeper on use cases and capabilities. That is a different campaign than a new logo every quarter.

The content has to match that. A lot of what these accounts need is education, tied to the pain that would make them buy and to the trigger that starts a purchase. The pain and the trigger belong to that account. If the piece is a product pitch, it is the wrong file. Command staff, an elected official, and an influencer inside the account do not read the same page.

## Surround the list

Reach that list before the event, on the channels they use. Each touch has one job. Get a specific person to a specific activation. The ask is a meeting, or a place to be, not a registration count.

The invitation should say why this event, why now, and why this person. A practitioner needs what they will learn that applies to the work. An approver needs what agencies like theirs are doing. Same event. Different reason to come.

Digital does something the floor cannot. It leaves a record. Who opened, who clicked, who ignored. That record sorts the list into people who are ready, people who are curious, and people who need a different approach. The sorting is the product of the pre-event work. The badge scan is late.

In this market the pre-event note has to stay educational. Agencies have rules about what a vendor can offer and who can meet whom. An invitation that is plainly about the work gets through. A sales pitch often does not.

## Be ready on the day

By the time the event opens, the meetings should already be booked. The team should know who is coming, which role they hold, what they have seen, and what to say first. A one-page brief is enough. It is the same shape as a seller playbook. The opportunity if there is one. The people. The touches that already happened. What the count leaves out.

The rest of the day is for the people you did not know to invite. Add them to the list, with a note on why, or the follow-up will treat them like a badge scan.

## The weeks after

Follow-up with sales is immediate. That part is not the hard timing problem. The hard timing problem is the market. Budget cycles make the year seasonal. A conversation in the wrong month dies, not because the account said no, but because the money is not there.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">With sales</span><strong>Immediate</strong><span>What the person did, and the next step. Not a note that they attended.</span></div>
<div class="jn-window-end"><span class="jn-label">Between budgets</span><strong>Grants</strong><span>Tied to the appropriations cycle, so the work stays alive when the budget window is closed.</span></div>
</div>

Someone who came to the activation gets a next step. Someone who registered and did not come gets a lighter ask. Someone who sat through one session gets the material on that topic. In a government account, keep a record of where they are in their own process. Enthusiasm does not set the pace. The budget does, and a grant tied to the appropriations cycle is how you work around a closed window.

A webinar is the same motion in a smaller room. Registrations are not the result. The questions are. Group them, summarize them, and that summary is input to the content agent for the next piece, still tied to the pain and the trigger. A survey at the end that asks whether the person wants to be contacted by sales is the fast path. The prompt is a gate a person set. The agent does not decide the lead is ready, and it does not send the lead on its own.

## Where it fails

The failure is usually timing. A physical event has latency, and the plan has to carry that latency or the month after the event does not exist. Pre-event is well understood. Logistics on the day sits with field, and that is a core competency. The break is what happens when the crates are packed.

<ol class="jn-steps">
<li><span class="jn-label">Before</span><span>The list, the campaigns, and the meetings. This part the team knows how to run.</span></li>
<li><span class="jn-label">Day</span><span>Activations, briefs, and the people who were not on the list. Field owns this.</span></li>
<li class="is-now"><span class="jn-label">After</span><span>The team is already on the next event. The weeks that would have produced the pipeline never run.</span></li>
</ol>

That third step is where people and agents work the same motion. An agent can group what was asked, keep the record of who did what, and draft the next educational piece inside the tier a person already approved. A person still owns the handoff to sales, the claim, and the decision to stop. The agent does not replace field, and it does not replace the seller. It holds the window open while the team has moved on. If the review pile grows, narrow what the agent starts. Do not add agents to outrun the people who have to say yes.

## The numbers

There is no cleared event result in this guide, and I am not going to state one.

The method is the part that lets the number be trusted when it exists. Define pipeline before you count it. Report sourced apart from influenced. They do not add together. Source is last touch, written at creation. It is the record of what the account was doing when it became a lead. It is not a claim that the event created the opportunity. Influenced is the multi-touch view. It can show that the event was in the path. It does not settle who sourced the deal.

Count unique opportunities. A deal touched three times is still one deal. Match cohorts by age. The delay between an event and an opportunity is long, and a current-year view can make events look slow when they are only late. Watch the catch-all. What you cannot trace lands in organic or direct, and a large bucket can change which channel ranks first.

<ul class="jn-check">
<li><label><input type="checkbox"> Build the microaudiences before you book anything. Agency level first, then the role inside the account.</label></li>
<li><label><input type="checkbox"> Drive those people to an activation. The ask is a meeting, not a badge scan.</label></li>
<li><label><input type="checkbox"> Follow up with sales immediately. Plan the weeks after before the event ends, or the team will already be on the next one.</label></li>
<li><label><input type="checkbox"> Group what people asked. A person still owns the handoff to sales.</label></li>
<li><label><input type="checkbox"> Report sourced and influenced apart. Source is last touch, written at creation.</label></li>
</ul>]]></content:encoded>
  </item>
<item>
    <title>Attribution that sales believes</title>
    <link>https://www.jeffnolan.com/field-guides/attribution-that-sales-believes/</link>
    <guid>https://www.jeffnolan.com/field-guides/attribution-that-sales-believes/</guid>
    <pubDate>Tue, 03 Nov 2026 00:00:00 GMT</pubDate>
    <description>How to get sales to accept the source on every opportunity: source means last touch, stamped at creation, and a seller playbook that makes the account concrete.</description>
    <content:encoded><![CDATA[## The problem

The first sign that sales does not believe your attribution is not an argument. It is silence. Nobody challenges the slide. They just stop using it.

Here is how it usually happens. Marketing reports a number. Sales has a different number for the same thing, pulled from a different view with different filters. Neither is exactly wrong. But now there are two numbers, and the conversation turns from what to do about pipeline into whose number is right. Sales wins that conversation every time, because sales owns the deals.

There is a quieter version. A deal closes that marketing clearly helped create, and the system gives marketing no credit, because of how a contact was tagged or how a field got filled in. Everyone in the room knows what happened. The record says otherwise. That is how you lose a sales team's trust. Not with a wrong number. With a right deal that the system will not admit to.

And there is the argument that does not work. Sales does not believe that digital channels produce results. They believe belly-to-belly selling is how companies succeed. Digital is abstract. They cannot touch it. Two pitches fail. One is that marketing will warm the account before sales gets it. Sales goes in from zero and believes they are the ones warming the account. The other is to trust the search counts. A seller does not believe a campaign because an account searched for us many times. Multitouch attribution can show that digital is a value driver. A seller still needs the account in their hands.

Attribution that sales believes is not a better model. It is a definition that sales helped write, a field that gets filled in at the right moment, and one place to look.

## The system

Three parts.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h12"/><path class="is-mark" d="M6 12h12"/><path d="M6 17h8"/></svg><span><span class="jn-label">Definition</span>Last touch, written with sales</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 5h12v14H6z"/><path class="is-mark" d="M9 12l2 2 4-4"/></svg><span><span class="jn-label">Stamp</span>At creation, not at reporting</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="3"/><path class="is-mark" d="M12 5v3M12 16v3"/></svg><span><span class="jn-label">One place</span>No opportunity without a source</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 7h12"/><path class="is-mark" d="M6 12h12"/><path d="M6 17h8"/></svg>One definition, written with sales</h3>

Before you count anything, agree what "sourced" means. Not "influenced." Sourced. The definition sales agreed to is last touch. It is not perfect. It is more realistic than first touch. What the account is doing when it converts to a lead is more directional than who created the account record. First touch answers who opened the record. Last touch answers what the account was doing when it became a lead.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">First</span><span class="jn-pillars-name">Who opened the record</span><span class="jn-pillars-q">Less directional.</span></li>
<li><span class="jn-pillars-n">Last</span><span class="jn-pillars-name">What they were doing</span><span class="jn-pillars-q">When the account became a lead. Not perfect. More realistic.</span></li>
</ul>

Write the surrounding rules down too, because they change the answer. What kind of revenue counts? Is it annual contract value, and is it weighted or unweighted? Are renewals in or out? Are hardware and services in or out? Each of those can move a share by several points, and each is a place where two people can disagree without either being wrong. Write the rules once and do not move them.

Keep sourced and influenced apart. Influenced pipeline can total more than sourced pipeline, because one opportunity gets touched by many things. Say once, clearly, that they are not additive. Then never add them.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Sourced</span><span class="jn-pillars-q">Last touch. One source on the opportunity.</span></li>
<li><span class="jn-pillars-name">Influenced</span><span class="jn-pillars-q">Many touches. Do not add it to sourced.</span></li>
</ul>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 5h12v14H6z"/><path class="is-mark" d="M9 12l2 2 4-4"/></svg>A source on every opportunity, at creation</h3>

A source that gets assigned at reporting time is a guess. A source assigned at creation is a record of that moment. What you write down is the last touch.

The reason is simple. By the time someone is reporting, the person who knew where the opportunity came from may have forgotten, left, or moved on to the next deal. The only moment the truth is cheap to record is the moment the opportunity is created. Make the field required at that moment. The answer is the last touch. Do not leave it blank.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="3"/><path class="is-mark" d="M12 5v3M12 16v3"/></svg>One place to look, and no blank source</h3>

Pick the view that wins. When two disagree, the named one is right until someone fixes the other. That sounds bureaucratic. It is the cheapest trust you can buy.

There is no reason for an opportunity to have no source. The last touch is known when the opportunity is created, and that is what gets written down. An opportunity without a source should not exist. It is not a bucket where credit goes to be argued about, and it is not a weekly queue.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 4v16"/><path class="is-mark" d="M6 5h10l-2 3 2 3H6"/></svg>When sales disagrees with a source</h3>

It will happen. A seller will look at an opportunity and say the source is wrong. Treat that as information, not an attack. Give sales a simple way to flag it, such as a field or a note, and a promise that someone looks within a set time. Then look. If the seller is right, fix the record and fix the cause. If the source is right, show how you know, in plain words, with the evidence the seller can check for themselves.

Do this a few times and something changes. Sales starts to see the source field as a shared record, not marketing's claim. Once the field is shared, the arguments about credit get shorter, because both sides are looking at the same facts.

## The numbers

One claim: 100% of sourced opportunities attributed to a channel. The period is 2026.

Read that claim carefully. It says every sourced opportunity carries a channel. It does not say marketing sourced a particular share of pipeline, and it does not say anything about revenue influence. I am keeping those out of this guide on purpose.

A claim like this has to say which population it covers. This one covers everything marketing sourced in 2026, and nothing else. It does not speak for opportunities that sales or anyone else created. Say that plainly wherever you quote it, because a reader who assumes it covers all pipeline will take away the wrong number.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">In</span><span class="jn-pillars-name">Marketing sourced</span><span class="jn-pillars-q">Everything marketing sourced in 2026.</span></li>
<li><span class="jn-pillars-n">Out</span><span class="jn-pillars-name">Everyone else</span><span class="jn-pillars-q">Opportunities sales or anyone else created.</span></li>
</ul>

## What you can take with you

Start with what failed. Sales does not believe digital channels produce results, because they cannot touch them. They believe belly-to-belly selling is how a company succeeds. The pitches that stay abstract fail. Marketing will warm the account before sales gets it. Trust the search counts. The seller goes in from zero and believes the warming is theirs. A count of searches is not a reason to believe.

What I would change is the thing we hand them. Build a seller playbook for each campaign member. Prime the seller with everything we know about that account and how it engaged the marketing. One page.

<ol class="jn-stages">
<li><span class="jn-label">Lead</span><span>Whether a lead is tied to the opportunity</span></li>
<li><span class="jn-label">Touches</span><span>In person next to digital, and how many people</span></li>
<li><span class="jn-label">Channels</span><span>The channels the account actually used</span></li>
<li><span class="jn-label">Timeline</span><span>Engagement up to the day it was created</span></li>
<li class="is-now"><span class="jn-label">Left out</span><span>What the count does not include</span></li>
</ol>

The order still matters. Sit down with sales first. Write the definition together. Source means last touch. It is not a perfect model. It is more realistic than first touch, because what the account is doing when it converts to a lead tells you more than who created the account record. Agree the place to look. Do not allow an opportunity with no source. Only then build the model. Multitouch attribution can show that digital is a value driver. It is still a view of influence. Last touch will not replace that view, and it will not be perfect. It is the source you can defend.

Here is the checklist.

<ul class="jn-check">
<li><label><input type="checkbox" /><span>Write the definition of source with sales, and put it in one place everyone can find.</span></label></li>
<li><label><input type="checkbox" /><span>Stamp the source when the opportunity is created, not when someone reports on it.</span></label></li>
<li><label><input type="checkbox" /><span>Do not create an opportunity with no source. The source is the last touch, written when the opportunity is created.</span></label></li>
<li><label><input type="checkbox" /><span>Name one place to look. When two views disagree, the named one wins.</span></label></li>
<li><label><input type="checkbox" /><span>Keep sourced and influenced apart, and say once that they are not additive.</span></label></li>
</ul>

If sales believes the label on the opportunity, you can have every other argument. If they do not, you cannot have any of them.]]></content:encoded>
  </item>
<item>
    <title>Fewer, bigger deals</title>
    <link>https://www.jeffnolan.com/field-guides/fewer-bigger-deals/</link>
    <guid>https://www.jeffnolan.com/field-guides/fewer-bigger-deals/</guid>
    <pubDate>Tue, 03 Nov 2026 00:00:00 GMT</pubDate>
    <description>How a marketing system can produce fewer opportunities and larger ones: what you stop chasing, what you aim at instead, and the caveats that keep the claim honest.</description>
    <content:encoded><![CDATA[## The problem

Most marketing plans have a volume target. More leads. More opportunities. More of whatever the dashboard counts. It is easy to set, easy to track, and easy to hit in a way that does nothing for the business.

The trouble with a count is what it rewards. The cheapest way to add opportunities is to chase the people who are already close: the ones who fill out a form, scan a badge, or download the guide. They are real, and they are small. A team measured on count will find a way to make more of them.

Meanwhile, the deals that move a business are bigger, slower, and involve several people. They rarely start with a form fill. They start with an account that has a problem, a group of people who each see part of it, and a vendor that shows up with something useful before anyone asked.

So a plan that says "more opportunities" and a story that says "fewer, bigger deals" point in opposite directions. If you want the second outcome, the plan has to measure it. This guide is about how a system can produce fewer opportunities and larger ones, and what you have to say alongside the numbers so the claim holds up.

## The system

Four moves.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Score dollars and conversion</span></li>
<li><span class="jn-label">2</span><span>Aim at the account</span></li>
<li><span class="jn-label">3</span><span>Stop the small work</span></li>
<li><span class="jn-label">4</span><span>Separate the reporting</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M12 4v14M8 20h8M4 9h16"/><path class="is-mark" d="M4 9c1.5 3 3 4.5 4 4.5S10.5 12 12 9"/><path d="M12 9c1.5 3 3 4.5 4 4.5S20.5 12 22 9"/></svg>Judge dollars and conversion, not counts</h3>

The first move is to change what gets scored. Pipeline dollars and conversion go on the scorecard. Opportunity counts stay on the page, but as a diagnostic. They tell you whether the engine is running. They do not tell you whether it is working.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">Score</span><span class="jn-pillars-name">Dollars and conversion</span><span class="jn-pillars-q">How many will convert, and how much they will spend.</span></li>
<li><span class="jn-pillars-n">Watch</span><span class="jn-pillars-name">Leads and opportunities</span><span class="jn-pillars-q">Whether the engine is running.</span></li>
</ul>

There is a real argument against this. Marketing's primary responsibility is filling the funnel, and giving those leads a quality dimension so they convert to sales-accepted leads. Marketing does not control the value of the opportunity. It is still the metric that matters, and using it is a judgment call. Leads and opportunities stay on the page. The dollar figure is what lets you see audience quality. It is not only how many will convert. It is how much they will spend.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="8" r="2.2"/><circle cx="7" cy="16" r="2.2"/><circle class="is-mark" cx="17" cy="16" r="2.2"/></svg>Aim at accounts and buying groups</h3>

The second move is the unit of work. For the accounts that matter most, the unit is the account, one use case, and the buying group around it. Not the contact. A contact is a person who might be a champion. An account with a use case is something you can build a plan around.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><rect x="5" y="5" width="14" height="14" rx="2"/><path class="is-mark" d="M9 12h6"/></svg><span><span class="jn-label">Account</span>The unit of work</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 6h10M7 12h10"/><path class="is-mark" d="M7 18h6"/></svg><span><span class="jn-label">Use case</span>One useful change</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="8" r="2.2"/><circle cx="7" cy="16" r="2.2"/><circle class="is-mark" cx="17" cy="16" r="2.2"/></svg><span><span class="jn-label">Buying group</span>Not a single contact</span></li>
</ol>

Aiming at the account starts from fit and a hypothesis about a useful change. The first offer is something of value, not a demo request. Sales accepts the opportunity on its own judgment. The result is fewer opportunities, because you are no longer counting every hand that goes up.

The plays that do this are account-based, for named accounts, and specifically 1:few. They produce outsize results on expansion opportunities inside existing customer accounts. What you want to see is higher ACV on that expansion than on a new logo. That is the motion working.

A buying group is usually three or four people with different jobs: someone who feels the problem, someone who evaluates the options, someone who controls the money, and someone who can say no. Marketing that reaches only the first person produces a nice conversation and a stalled deal. Marketing that reaches the group, each with a reason that fits their job, produces the kind of opportunity that is larger and slower and more likely to close.

<ol class="jn-stages is-four">
<li><span class="jn-label">Feels</span><span>The problem</span></li>
<li><span class="jn-label">Evaluates</span><span>The options</span></li>
<li><span class="jn-label">Pays</span><span>Controls the money</span></li>
<li><span class="jn-label">Blocks</span><span>Can say no</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M8 16l8-8"/></svg>Stop the work that makes small opportunities</h3>

Fewer opportunities does not happen by itself. Somebody has to stop something. Programs that produce volume with no path to a large deal are the first candidates. Cutting them lowers the count on its own.

We stopped running evergreen campaigns. They were never really evergreen. The campaign was constantly updated, and the audience was not. We also stopped product-specific campaigns. They matched how we defined going to market, not how people wanted to buy. The focus now is audience segments and solution categories.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">Was</span><span class="jn-pillars-name">Evergreen</span><span class="jn-pillars-q">The campaign was updated. The audience was not.</span></li>
<li><span class="jn-pillars-n">Was</span><span class="jn-pillars-name">Product</span><span class="jn-pillars-q">How we go to market, not how people buy.</span></li>
<li><span class="jn-pillars-n">Now</span><span class="jn-pillars-name">Segments</span><span class="jn-pillars-q">Audience segments.</span></li>
<li><span class="jn-pillars-n">Now</span><span class="jn-pillars-name">Solutions</span><span class="jn-pillars-q">Solution categories.</span></li>
</ul>

Here is the test I use. If the count falls and the dollars hold or rise, the system is working. If the count falls and the dollars fall with it, you did not build a better engine. You built a smaller one. That is why the dollar number and the count have to sit side by side.

<div class="jn-matrix">
<span class="is-head"></span>
<span class="is-head">Dollars hold or rise</span>
<span class="is-head">Dollars fall</span>
<span class="is-head">Count falls</span>
<span class="is-now">The system is working.</span>
<span>A smaller engine.</span>
</div>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 6h6v12H4z"/><path class="is-mark" d="M14 6h6v12h-6z"/></svg>Keep new business separate from expansion</h3>

The fourth move is reporting. Expansion in the installed base is real, and it is a different job from winning a new logo or expanding the portfolio with an existing customer. If you blend them, expansion credit can flatter the whole story and hide what the strategic motions are doing. So I report New Logo and Portfolio Expansion on their own, with expansion alongside as context.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 18V8"/><path class="is-mark" d="M6 8l4 4"/></svg><span><span class="jn-label">New Logo</span>Its own number</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 18V8M12 18V6"/><path class="is-mark" d="M12 6l4 3"/></svg><span><span class="jn-label">Portfolio</span>Expansion, on its own</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 16h14"/><path class="is-mark" d="M8 16v-4M16 16v-4"/></svg><span><span class="jn-label">Installed base</span>Context, not blended in</span></li>
</ol>

## The numbers

I keep each of these as its own number. I am not combining them into one percentage, and they do not stack.

Marketing-sourced new-business ACV was up 25% on 11% fewer opportunities. The period is 2026 year to date.

Average deal size per sourced opportunity was up 41%. The period is 2026 year to date.

Marketing-sourced deals win more often: a 40% vs 34% ACV win rate over five quarters. The period is over five quarters.

New Logo ACV was up 42%. The period is 2026 year to date. Portfolio Expansion ACV was up 62%. The period is 2026 year to date.

These numbers are different cuts of the same business. Read them together, and do not turn them into one headline. Sourced ACV rose while the opportunity count fell. Deal size rose. Win rate is higher for marketing-sourced deals. Each claim has its own period and its own definition. The 2026 figures are year to date, so they will move before year end.

Now the caveat that matters. The 41% is an average, and an average can be skewed by a few large deals. Anyone reading it should ask for the median, and for the average without the largest deals. I would rather you ask than assume.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 16h14"/><path class="is-mark" d="M12 6v8"/></svg><span><span class="jn-label">Median</span>Next to the average</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 16h14"/><path class="is-mark" d="M8 16V8M16 16v-5"/></svg><span><span class="jn-label">Average</span>The 41% figure</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M5 16h10"/><path class="is-mark" d="M17 7l3 3-3 3"/></svg><span><span class="jn-label">Without the largest</span>What a few wins are carrying</span></li>
</ol>

## What you can take with you

Start with what failed. When an audience gets very small and is not differentiated, you create adjacent audiences that step on each other. The other failure is time. If the timeline from concept to execution stretches out, the cost equation for a campaign aimed at a smaller, more specific audience evaporates. You are better off pulling the plug.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Not distinct</span><span class="jn-pillars-q">Adjacent audiences step on each other.</span></li>
<li><span class="jn-pillars-name">Too slow</span><span class="jn-pillars-q">The cost equation evaporates. Pull the plug.</span></li>
</ul>

What I would change is to pick one primary measure before the year starts and make the plan and the story agree. I would put median deal size next to the average, and show the average without the largest deals, so a reader can see how much of the gain rests on a handful of wins. And I would report New Logo and Portfolio Expansion first, with expansion as context.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>One primary measure</span></li>
<li><span class="jn-label">2</span><span>Median beside the average</span></li>
<li><span class="jn-label">3</span><span>Average without the largest</span></li>
<li><span class="jn-label">4</span><span>New logo and expansion apart</span></li>
</ol>

Here is the checklist.

First, pick one primary measure. If the plan says count and the story says size, fix the plan.

Second, judge programs on pipeline dollars and conversion. Keep opportunity counts as a diagnostic.

Third, report median deal size next to the average.

Fourth, report the average without your largest deals.

Fifth, separate new business from expansion in the installed base before you claim credit.

Fewer, bigger deals is a good outcome. It is also an easy one to overstate. The way to keep it honest is to show the number that could embarrass you, right next to the number that makes you look good.]]></content:encoded>
  </item>
<item>
    <title>Pipeline per program dollar</title>
    <link>https://www.jeffnolan.com/field-guides/pipeline-per-program-dollar/</link>
    <guid>https://www.jeffnolan.com/field-guides/pipeline-per-program-dollar/</guid>
    <pubDate>Tue, 03 Nov 2026 00:00:00 GMT</pubDate>
    <description>The system behind a 20:1 to 28:1 move in pipeline per program dollar: a gate in front of every dollar, a habit of cutting what does not convert, and a definition you can audit.</description>
    <content:encoded><![CDATA[## The problem

Ask a marketing team what a program dollar bought and you usually get a number and a shrug. The number moves depending on who is asking. Sometimes it counts people. Sometimes it counts events. Sometimes it counts only the media.

That is the problem this guide is about. Efficiency is easy to claim. It is hard to audit. A ratio that nobody can audit is a slogan, and a sharp reader will treat it like one.

There is a second problem hiding behind the first. Even when a team defines the ratio well, it often cannot say which change moved it. The ratio went up. Was it a better brief? A cut program? A channel that matured? A bigger deal that landed in the window? If you cannot answer, you cannot repeat it.

This is not a tour of every efficiency metric. It is one ratio, pipeline per program dollar, and the system that moved it.

## The system

Three parts. A gate in front of every dollar. A loop that carries what you learned into the next decision. And a willingness to retire what does not work.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 5v14"/><path d="M4 8h9l3 4-3 4H4"/><path class="is-mark" d="M16 12h4"/></svg><span><span class="jn-label">Gate</span>In front of every dollar</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 9h9a4 4 0 0 1 0 8H9"/><path class="is-mark" d="M9 14l-3 3 3 3"/></svg><span><span class="jn-label">Loop</span>Learning into the next brief</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M8 16l8-8"/></svg><span><span class="jn-label">Retire</span>Stop what does not convert</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 5v14"/><path d="M4 8h9l3 4-3 4H4"/><path class="is-mark" d="M16 12h4"/></svg>Gates before money moves</h3>

Every campaign runs through five stages. A strategic brief. A regional adaptation plan. Build and produce. Launch and execute. Report and learn. Each stage ends in a gate, and each gate has an artifact. No artifact, no handoff.

<ol class="jn-stages">
<li><span class="jn-label">Brief</span><span>Strategic brief</span></li>
<li><span class="jn-label">Adapt</span><span>Regional adaptation</span></li>
<li><span class="jn-label">Build</span><span>Build and produce</span></li>
<li><span class="jn-label">Launch</span><span>Launch and execute</span></li>
<li class="is-now"><span class="jn-label">Learn</span><span>Report and learn</span></li>
</ol>

The brief is where the money gets decided. It has an objective, a target audience and ICP, messaging, content pillars, success metrics, a timeline, and a budget by region. Field teams get a review window before it is final. Success metrics are defined before launch, not after. That one rule does more for the ratio than any tool. You cannot quietly redefine success when the results come in if you wrote it down on day one.

Gates also change who argues with whom. When the budget and the metrics are written into the brief, the argument happens before the money is spent, when it is cheap, instead of after, when it is a postmortem.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M6 9h9a4 4 0 0 1 0 8H9"/><path class="is-mark" d="M9 14l-3 3 3 3"/></svg>The loop</h3>

The last stage matters most for efficiency. Report and learn is not a ceremony. When the performance report is filed, what you learned goes straight back into the next brief. The loop closes on its own, so nobody has to remember to do it.

Without the loop, every campaign starts from a blank page. With it, the second campaign in a series has the first one's results sitting in its brief, and the third has both. Efficiency compounds when learning does.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><circle cx="12" cy="12" r="7"/><path class="is-mark" d="M8 16l8-8"/></svg>Retiring what does not work</h3>

A gate only helps if something fails it. The third habit is to stop funding programs that cannot show a path to pipeline, and to say so out loud. It is uncomfortable. Every program has an owner who believes in it. But a ratio can only improve if the denominator gets spent on things that convert, and that means some things have to stop.

We stopped running campaigns for products. Campaigns now go to audiences, and they promote capabilities. The product is still there. It is no longer what the campaign is organized around. The audience is who the dollar is spent against, and the capability is what the message is allowed to say.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">Was</span><span class="jn-pillars-name">Products</span><span class="jn-pillars-q">Campaigns organized around the product.</span></li>
<li><span class="jn-pillars-n">Now</span><span class="jn-pillars-name">Audiences</span><span class="jn-pillars-q">Campaigns promote capabilities.</span></li>
</ul>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 7h10"/><path class="is-mark" d="M5 12h14"/><path d="M7 17h10"/></svg>Reading the ratio</h3>

A ratio has two halves, and either one can move it. Pipeline per program dollar goes up when pipeline grows, and it goes up when spend shrinks. Both are fine, but they are different stories, and a reader deserves to know which one they are looking at. Show the numerator and the denominator next to the ratio, with the period on both.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">Up</span><span class="jn-pillars-name">Pipeline</span><span class="jn-pillars-q">The ratio rises when pipeline grows.</span></li>
<li><span class="jn-pillars-n">Down</span><span class="jn-pillars-name">Spend</span><span class="jn-pillars-q">The ratio rises when spend shrinks.</span></li>
</ul>

Watch for timing too. Pipeline created this year may come from work done last year, and spend this year may fund pipeline that lands next year. A ratio that compares the two without saying so is quietly mixing periods. The fix is boring: state the window, state the basis, and keep both the same from one quarter to the next.

## The numbers

Two claims. I keep them separate from each other and from every other metric.

First: 28% more pipeline per program dollar, year over year (2026 year to date vs 2025; from 20:1 to 28:1). The period is 2026 year to date vs 2025. The ratio went from 20:1 to 28:1. The 28% is the change in that ratio.

Second: Prior full year's pipeline beaten on about 74% of the spend. The period is the prior full year. This is a different claim from the first.

Before you quote any version of this ratio, you need one definition of program spend, and you need to use it the same way every time. Program spend is everything not associated with headcount. Advertising counts. Data acquisition counts. Promoted social media counts. Paid search counts. Headcount does not.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">In</span><span class="jn-pillars-name">Program spend</span><span class="jn-pillars-q">Advertising, data acquisition, promoted social media, paid search.</span></li>
<li><span class="jn-pillars-n">Out</span><span class="jn-pillars-name">Headcount</span><span class="jn-pillars-q">People are not in the denominator.</span></li>
</ul>

Pipeline per program dollar improves because the campaigns are built to deliver a targeted return and then conclude. We do not run evergreen campaigns. The aim is to maximize a campaign's performance within 45 to 90 days, then move on to the next one. A shorter time to value, together with a tiny audience, means more campaigns can run in parallel. That is where the effect compounds.

<div class="jn-window">
<div class="jn-window-run"><span class="jn-label">In market</span><strong>45 to 90 days</strong><span>Maximize performance, then conclude.</span></div>
<div class="jn-window-end"><span class="jn-label">Then</span><strong>Move on</strong><span>No evergreen campaign.</span></div>
</div>

I am leaving cost per lead, cost per qualified lead, and cost per opportunity out of this guide on purpose. They are real metrics, and they tell a different story.

## What you can take with you

Start with what failed. Communication across the team failed. So did the Spider-Man effect: everyone pointing at someone else, even when they had the authority to decide. And suboptimal performance was not recognized early in the cycle.

A small audience is not enough if it is not distinct. Campaigns then step on the campaigns next to them, and the audiences overlap. The other failure is building the audience with no external signals. That audience is inside-out. Internal data alone optimizes for our own definition of success, and the work spirals into chasing the same subset of customers again.

<ul class="jn-pillars">
<li><span class="jn-pillars-name">Not distinct</span><span class="jn-pillars-q">Small audiences overlap, and campaigns step on each other.</span></li>
<li><span class="jn-pillars-name">Inside-out</span><span class="jn-pillars-q">No external signals. The work chases the same customers.</span></li>
</ul>

What I would change is the order. Define the ratio first. Agree the definition with finance and with sales operations. Then set the gates. Then decide what to retire. A team that does it in the other order spends a quarter arguing about whether the number is right.

<ol class="jn-stages is-four">
<li><span class="jn-label">1</span><span>Define the ratio</span></li>
<li><span class="jn-label">2</span><span>Agree it with finance and sales operations</span></li>
<li><span class="jn-label">3</span><span>Set the gates</span></li>
<li><span class="jn-label">4</span><span>Decide what to retire</span></li>
</ol>

Here is the checklist.

First, write down what counts as program spend, and keep it fixed from one quarter to the next.

Second, put a gate in front of every program. Success metrics get defined before launch.

Third, feed what each campaign learned into the next brief. Make the loop automatic.

Fourth, retire programs that cannot show a path to pipeline, and say so out loud.

Fifth, state the period and the baseline every time you quote the ratio. A number without a period is the fastest way to lose a room.]]></content:encoded>
  </item>
<item>
    <title>Building tiny audiences</title>
    <link>https://www.jeffnolan.com/field-guides/tiny-audiences/</link>
    <guid>https://www.jeffnolan.com/field-guides/tiny-audiences/</guid>
    <pubDate>Tue, 03 Nov 2026 00:00:00 GMT</pubDate>
    <description>How signals split one broad segment into many small audiences, each with its own campaign, behind three guardrail tiers. Plus the size floor and when to merge back.</description>
    <content:encoded><![CDATA[## The problem

A broad segment is a label. "Mid-size IT teams." "Public sector buyers." One campaign goes to the label, and the message has to work for everyone under it. It ends up working well for almost no one.

The label tells you very little. It does not say who is actually in the market this quarter. It does not say what they have already seen from you. It does not say whether the person reading is the one who uses the product or the one who signs for it. Everyone gets the same email, the same ad, the same landing page, and the same result: a little interest from a lot of people who were never going to buy.

The fix sounds simple. Split the segment. Make many small audiences, give each one its own campaign, and let the message fit the people in it.

The catch is the math. Many audiences means many campaigns. Many campaigns means many chances for copy to wander away from claims you can defend. Every extra audience is another place for a headline to promise something the product does not do. So the split only works if something holds the edges. That something is a set of guardrail tiers, and I want them in place before I split anything.

## The system

Three parts. A score decides which accounts belong in a small audience. Tiers decide what can change from one audience to the next. Intake decides whether an audience can actually be built and measured.

<ol class="jn-steps">
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 18V14M9 18V11M14 18V8"/><path class="is-mark" d="M19 18V5"/></svg><span><span class="jn-label">Score</span>Which accounts belong</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path class="is-mark" d="M4 7h16"/><path d="M4 12h12M4 17h8"/></svg><span><span class="jn-label">Copy tiers</span>What can change</span></li>
<li><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 4v16M17 4v16M7 8h4M13 8h4"/></svg><span><span class="jn-label">Intake</span>What can be built</span></li>
</ol>

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 18V14M9 18V11M14 18V8"/><path class="is-mark" d="M19 18V5"/></svg>Signals worth wiring first</h3>

A small audience starts as a score on the account, not a label. The score answers four questions. Is this a fit? Is there a reason to call now? Is the account already showing intent? Can a seller act on it?

The weights are a strawman for sales and marketing operations to challenge. They are a model, not a result. Meridian is not a real product. It stands in for the product-specific signals. A contact does not get a separate score. One input asks whether a named buyer at the account can be reached.

Fit is stable. Why now and intent move month to month, so those two decide who gets worked this quarter. Together they separate a large account that is quiet from a smaller one that just got a grant, a new leader, and a trial signup.

<ul class="jn-pillars">
<li><span class="jn-pillars-n">35</span><span class="jn-pillars-name">Fit</span><span class="jn-pillars-q">Should we want this account?</span></li>
<li><span class="jn-pillars-n">35</span><span class="jn-pillars-name">Why now</span><span class="jn-pillars-q">Is something changing that opens budget or attention?</span></li>
<li><span class="jn-pillars-n">20</span><span class="jn-pillars-name">Intent</span><span class="jn-pillars-q">Are they already moving toward us?</span></li>
<li><span class="jn-pillars-n">10</span><span class="jn-pillars-name">Relationship</span><span class="jn-pillars-q">Can a seller act on it?</span></li>
</ul>

Population is public, so it is the base of Fit. A district with no population of its own uses the sum of the places it covers. The bucket runs from 1 to 5, then multiplies by 3.

| Population | Points |
| --- | --- |
| Under 50,000 | 3 |
| 50,000 to under 100,000 | 6 |
| 100,000 to under 200,000 | 9 |
| 200,000 to under 500,000 | 12 |
| 500,000 and over | 15 |

| Pillar | Signal | Points | Rule |
| --- | --- | --- | --- |
| Fit | Population | 15 | The buckets above |
| Fit | Meridian footprint | 12 | Active 12, lapsed 6, none 0 |
| Fit | Meridian whitespace | 8 | Has a footprint but not the full product 8, partial 4, fully deployed or no footprint 0 |
| Why now | Leadership change | 8 | New leader in the last 12 months 8, 12 to 24 months 4 |
| Why now | Grant award | 8 | $250,000 or more 8, $50,000 or more 5, any award 3 |
| Why now | Bond or referendum | 5 | A public-safety or justice bond passed, inside a 24-month window |
| Why now | Population growth | 4 | The place is over the growth threshold |
| Why now | Crime and caseload | 5 | Caseload up 10% or more year over year |
| Why now | Contract or competitor rebid | 5 | Your contract, or a competitor's, ends within 18 months |
| Intent | Intent score | 10 | The intent score divided by 10, rounded |
| Intent | Digital engagement | 6 | A Meridian trial or a sales inquiry in the last 90 days |
| Intent | Open pipeline | 4 | Any open opportunity |
| Relationship | Account health | 3 | Green 3, yellow 1, red 0 |
| Relationship | Reference | 2 | Flagged as a reference |
| Relationship | Hosted event | 2 | Has hosted an event |
| Relationship | Reachable contact | 3 | A buyer-role contact with a checked phone or email |

The maximum is 100. Leadership and grants are both 8 on purpose. Both are time-limited reasons to call, and there is not yet enough evidence to say one predicts better than the other.

Why now signals carry a date and an expiry. Points fade in a straight line to zero at expiry, so a change that is almost at the end of its window counts for almost nothing. A flag that has not been checked scores zero. That is missing data, not a penalty. Record how many of the 16 inputs were actually observed. A thin-data account is unknown, not weak.

Build the list from every active account you might market to, with its population and its Meridian footprint. Score Fit from population, footprint, and whitespace. Attach Why now, then intent, then relationship. Sum to a score from 0 to 100. Write the score, the score tier, the lane, and the top three reasons back to the account, so a seller can see why it ranks where it does.

These score tiers are not the Locked, Flexed, and Free tiers later in this guide. Those govern copy. These only rank accounts. The top tier is also capped by how many accounts sellers can actually work. The strawman cap is 500. The cutoffs are placeholders until the score has been run across the whole list and the distribution is visible.

| Score tier | Rule | Treatment |
| --- | --- | --- |
| 1 | 65 or above, capped at the top 500 | Named seller, an account brief, and a sequence |
| 2 | 45 to 64 | Seller-assisted outreach when a trigger fires |
| 3 | 25 to 44 | Marketing-led nurture |
| 4 | Under 25 | Awareness only |

Inside a score tier, sort by Why now plus intent, then by population.

A customer in trouble and a new account with the same score do not need the same call. Each account gets one lane, and the ranking runs inside the lane.

| Lane | Who | What the score is for |
| --- | --- | --- |
| Retain | Red health, or a renewal inside 12 months with yellow or red health | Order the save list |
| Expand | Active Meridian footprint, health green or yellow | Order the expansion list |
| Win back | Lapsed Meridian footprint | Order the reactivation list |
| New logo | No footprint | Order the acquisition list |

Fit and timing together decide the motion. Timing is Why now plus intent.

<div class="jn-matrix">
<span class="is-head"></span>
<span class="is-head">Timing low</span>
<span class="is-head">Timing high</span>
<span class="is-head">Fit high</span>
<span>Prime. Calendar triggers, association events, nurture.</span>
<span class="is-now">Work now. A seller, a brief, and a sequence this month.</span>
<span class="is-head">Fit low</span>
<span>Deprioritize. Awareness only.</span>
<span>Opportunistic. Digital and low-touch. No field time.</span>
</div>

The signal that fired chooses the opening message. A leadership change gets a reintroduction in the first 90 days. A grant means confirming the award is earmarked for the product before the cycle closes. A bond means getting into the process while the product is being budgeted. Population growth means planning capacity ahead of the workload. A caseload increase means showing how similar organizations handled the higher workload. Digital engagement means following up on a trial or inquiry the account started. A competitor rebid is a displacement play timed to that contract's end. A joint program, a procurement, or a conference can use the same plays once those signals are being collected. They are not in the score yet.

The weights stay a hypothesis until engagement tests them. Hold out similar accounts that sellers do not work from the list. Compare engagement at the top of the ranking with engagement at the bottom. Reweight toward the signals that predicted engagement. Do not tune the weights to a small sample.

A signal that is almost never filled in does not change the ranking, so do not pretend those points are in play. A health score that covers only a slice of accounts leaves the retain lane blind everywhere else. A caseload signal that covers only large organizations gives smaller ones no credit. A competitor name that is missing leaves the rebid date usable and the "who" unknown. An account with no match in the system of record gets no intent or contract points. Treat that account as unknown.

Four calls are still open, and each belongs with sales and marketing operations. Is 35 / 35 / 20 / 10 right, or should timing outweigh fit for a quarter-long push? Is 500 the real seller capacity, and is that cap total or by region? Should an active footprint raise the score, favoring expansion, or lower it, favoring new logos? Does the retain lane share one ranking with the others, or run as its own list?

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path class="is-mark" d="M4 7h16"/><path d="M4 12h12M4 17h8"/></svg>The tiers</h3>

The tiers are the guardrail. There are three.

<ol class="jn-tiers">
<li><span class="jn-label">Locked</span>Use the claim as written.</li>
<li><span class="jn-label">Flexed</span>Adapt the copy. Do not change the claim.</li>
<li><span class="jn-label">Free</span>Local work, inside the same audience.</li>
</ol>

Tier 1 is Locked. Core brand messaging and product positioning, sourced from Product Marketing. Field uses it as is. They can choose which elements to emphasize, but they do not edit it. Product descriptions, competitive positioning, pricing messaging, and compliance or legal language live here.

Tier 2 is Flexed. Campaign-level copy, set by the campaign team with Field input. Headlines, email subject lines, ad copy. Field can adapt it for a region. They can change tone for local business culture, translate copy, or lean on a different content pillar that fits a regional pain point. They cannot introduce a new value proposition, change the target audience, or contradict a product claim.

Tier 3 is Free. Field creates it on their own. Local event promotions, partner co-marketing materials, regional customer spotlights.

Here is what that means for small audiences. Every audience gets the same Locked claims. What changes between audiences is Flexed copy and, where it fits, Free content. The audience itself is not something a region invents mid-flight. The campaign team defines target audience and ICP. Field prioritizes by region.

That split of decision rights matters more than it sounds. Without it, a small audience becomes a place to quietly smuggle in a new claim.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M7 4v16M17 4v16M7 8h4M13 8h4"/></svg>Intake</h3>

An audience is not real until marketing operations has built it. Their ask is plain. Requirements come in through an intake form, with the lead time they need, clean audience segmentation criteria, and success metrics defined before launch.

The criteria are the part people skip. "Prospects who showed interest" is not a criterion. A field, a value, and a date range is. If operations cannot build the audience from what you wrote down, the audience does not exist yet, and the campaign will run against a list someone assembled by hand. That list will not be refreshed, and it will not be measurable.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 18h16"/><circle class="is-mark" cx="12" cy="10" r="2.5"/></svg>The segment-size floor</h3>

There is no floor I can hand you. Every company has to set its own, and it is a Goldilocks problem. Too small, and you cannot tell whether the message worked or you got lucky. Too large, and the audience is a label again. The analytics on campaign performance are how you find the line. An audience under the floor can still be worth serving. It rides inside a neighboring audience until it is large enough to read on its own. It does not get its own campaign, its own copy, or its own report.

<h3 class="jn-mark"><svg class="jn-ico" viewBox="0 0 24 24" aria-hidden="true"><path d="M4 7l8 6 8-6"/><path class="is-mark" d="M12 13v6"/></svg>When to merge an audience back</h3>

Merge two audiences when you cannot tell their results apart. Compare them on the same metric, over the same period, with enough volume to read. If different copy produces the same outcome, the split is costing work and buying nothing. If one outperforms the other, keep them apart. That difference is the reason the audience exists.

Do not merge because the report looks messy. A clean report is often a sign you are looking at an average.

The floor is the other half of the same test. Below it, you cannot compare anything, so an audience that stays under the floor goes back inside a neighbor. The campaign and the Flexed copy for that audience stop. The Locked claims were already shared.

A stale signal is not, by itself, a reason to merge. Rescore the account. Merge only if performance then converges, or the audience falls under the floor and stays there. The call belongs to the person who defined the audience. They are the one who has to retire it.

## The numbers

I am not claiming that splitting audiences caused the pipeline-per-program-dollar result at the end of this guide. I am not claiming that it did not. What we did was read campaign performance across smaller segments, looking for the Goldilocks size.

What the operating model has given us is consistency and predictability, from the concept of a campaign through execution and review. As the time to deliver came down, we could run campaigns that were not practical before. When the internal cost of standing a campaign up is nominal, a campaign against a small segment is affordable. If a campaign takes six months to build, it has to aim at a large segment, and the message gets generalized for that broad audience instead of a small one.

I am not mixing this with cost per lead or cost per qualified lead. Those are different metrics. They stay out of this guide.

## What you can take with you

Start with what failed. The split fails when it happens before the rules exist, and two things break at once. The copy drifts. Each new audience is another place to say something the product does not do, and Flexed copy gets treated as permission to change the claim. Then the segment is too small to read, so a review cannot tell a drifted claim from a win. You find both in the performance report, which is the expensive time to find them. The other failure is earlier. If a campaign still takes months to build, the small audience never gets made. The message is generalized for a large segment, because that is the only size that can carry the cost.

What I would change is the order. Lock the claims before the first split. Write the audience so operations can build it before the copy is written. Set the floor and the merge rule before launch, so you are not deciding under pressure after a campaign has been running for a month. A stale or missing signal is not a segment. It is an account you have not measured yet.

Here is the checklist.

First, write the audience down in full. Who is in it, what signal puts them there, and what they should see next.

Second, tag every audience's copy Locked, Flexed, or Free before anything is built. If a piece of copy changes the target audience, it is not Flexed. Send it back to the campaign team.

Third, give operations clean segmentation criteria and success metrics, and respect their lead time.

Fourth, set the size floor from your own campaign performance before launch, not after. Merge two audiences when you cannot tell their results apart, or when one stays under the floor. A stale signal is a reason to rescore, not a reason to merge by itself.

Small audiences are worth the work when the message fits the people in them. They are not worth it if each one is a new place for a claim to drift.]]></content:encoded>
  </item>
<item>
    <title>Campaigns in minutes, not months.</title>
    <link>https://www.jeffnolan.com/builds/campaigns-in-minutes/</link>
    <guid>https://www.jeffnolan.com/builds/campaigns-in-minutes/</guid>
    <pubDate>Sun, 01 Nov 2026 00:00:00 GMT</pubDate>
    <description>How I turned a campaign process into a campaign system: standardize, automate, then go agentic.</description>
    <content:encoded><![CDATA[Most B2B marketing teams hit the same wall: campaigns take months, and most of that time is handoffs. The way through starts with the unglamorous part. First, standardize. Write an operating model with five stages, each with one owner, one handoff artifact and one gate you must clear before moving on. No artifact, no handoff. Split messaging into three tiers (locked, flexed and free) so everyone knows exactly what they can change, and measure the process itself, not just the campaigns. Second, automate. Once the process is written down, every step can run as a workflow. I use n8n. Briefs, adaptations, build checklists, launches and reports become workflows instead of meetings. Third, go agentic. When the process runs as software, the unit of work shrinks. You can define a very small audience from internal and external signals and have a campaign built to target it in minutes rather than months, without burning the team's time on campaign assembly. The gates stay, but they become permissions: what an agent may use as-is, what it may adapt, and what a human must approve. None of this depends on one company or one stack. In my most recent role it produced 28% more pipeline per program dollar, year over year. To show what it can do for any B2B team, the model below runs the math on public benchmarks and assumptions you can see and change. It is an illustrative model, not client results.]]></content:encoded>
  </item>
</channel>
</rss>