The Advisor: a campaign plan from a brief
The Advisor turns a Campaign Brief into a plan: pools, the messages each carries, and the articles to point at.
The brief
Objective, goal with a number, target, what they believe now, what they must believe, the offer, and the proof. Short answers work.
Planning for specific ICPs
Once the positioning has cards under Identity > Targets, the brief asks Which ICPs is this campaign for? Tick one or more and the plan becomes a grid, decided in this order:
- The campaign: what it has to achieve.
- The pool intents: the jobs the campaign needs done, decided once.
- One pool per intent per ICP. The same job for two ICPs is two pools, because each has its own reader and its own filter. A cell is left out when the job does not apply to that ICP, and the plan says so.
Each pool line shows who it is For and its Filter: what that ICP's card implies (job title, industry, country), how many contacts matched at the last HubSpot check, and a warning when HubSpot holds too little to filter on. Only send to this ICP is ticked; approving the line puts the filter on the pool in the campaign. Untick it first to leave the pool open to everyone. You can change the filter later on the campaign like any other.
A filter can only see what a contact record holds. If nobody in HubSpot matches yet, the pool sends to no one until that audience is built: the line tells you.
What kind of series? sets the shape: Welcome, Nurture, Re-engagement or Onboarding, each with how many messages, how far apart, and the job of each. Leave it on None and the planner shapes the argument itself.
A pool built this way remembers its ICP. Draft rows with AI in that pool writes to that person without being told.
Planning by lifecycle stage
Which lifecycle stages does it write for? lists your portal's HubSpot lifecycle stages, custom ones included. Tick the stages the campaign is for and the plan writes one pool per stage (one per stage per ICP when ICPs are ticked).
Each pool line shows its Stage, the reader at that stage (problem-aware, solution-aware, product-aware, most aware) and the move it is for: lead to MQL, MQL to SQL, and so on. The messages open where that reader is. A problem-aware reader is not sold a product; a product-aware reader is not taught the problem again.
The filter is set by mxAURA, not written by the AI: lifecycle stage is that pool's stage, added to the ICP filter when there is one. Tick No stage set for a qualifying pool that catches everyone whose stage is blank or not ticked. HubSpot stays the record: the stage is read at every send, so a contact who moves from Lead to MQL meets the MQL pool on their next send.
A ticked stage with no pool written for it is said on the plan. So is a pool that names no stage.
Two more brief lines help: What does it want from the reader? (one sentence, the move) and What starts a contact on it? (a form, a list, a stage change). The campaign page shows the brief it was planned from, collapsed above the pools.
What HubSpot shows
Before it plans, the Advisor reads the account's HubSpot record (Identity > Targets, the panel at the top): how many contacts and customers there are, who the customers are against everyone else, and the portal's posture. Rich: the plan leans on the portal where it and the positioning disagree about who the customer is. Messy: only the filled fields count; the positioning decides. Blank: the portal is silent and the positioning decides. The posture the plan was built on is logged with every plan.
Stakes: what changed, what it costs, what good looks like
Three optional lines make a true campaign matter. What changed in the world is the shift the reader is living through, in their terms; teach beats carry it. What does it cost to ignore is the stakes, grounded in a number or a consequence the world set, never one we invented; reframe beats carry it, and the enemy they name is the old way the reader is still running, never a competitor. What good looks like on the other side is the win in the reader's terms; prove beats show it. Desire is never performed: the stakes are stated plainly and the reader supplies the wanting.
Writing the pools in the background
Once a plan has pools, Write pools in the background approves any pool not yet built, then queues one write job per pool. Each job drafts the pool's rows through the Composer from the plan (brief, this pool's job, the stage, the stakes), scores them with the three critics, and adds the kept drafts as Draft rows in the pool, filed in the campaign's message folder and recorded on the plan. A draft the guardrails block is held back and counted. The AI Queue shows progress; a notification arrives per pool with the rows added and the critic scores. Nothing goes live until you make each row Ready.
Existing pools come first
The plan reads the account's pools and live articles before it proposes anything. Each planned pool says whether to use an existing pool as is, adapt one (clone and change), or create a new one, with the reason. Invented pools are never silently created.
Approving
Approve line by line. Approving creates or clones pools, makes a folder per resource type named for the campaign, attaches pools to the campaign, and records what the plan built. The campaign page then marks each pool as created here, reused or adapted, and a pool's page shows its purpose in the plan.
Drafting the messages
Open a planned pool and use Draft rows with AI. The Composer reads the plan: the brief, this pool's job and outline, the other pools, and your live articles. See Composer.