AI Content Planning Workflow: Inside a $3,000 Build for a Marketing Team

Each planning window looked the same at this client. Somebody opened a blank doc or a fresh chat. Somebody else hunted through Notion, Drive, old briefs, and the deck from last quarter. Performance notes lived in a spreadsheet only one person could read, and the brand rules lived in a PDF nobody ever pasted in.

The calendar came back incomplete, generic, or disconnected from what the company actually sold — not because the tool was weak, but because the context was reassembled from scratch by whoever happened to be free that week.

Their strongest marketer had a prompt that worked. It produced a strong plan once. The next cycle the instructions changed with whoever asked, the good output still needed repair, and the real method stayed in two people’s heads. That is the drift described in why team AI knowledge needs a shared system, and content planning is an unusually clear case of it because the output is judged by a different person every time.

The tell was repair work. The same reviewer fixed the same three things every cycle — missing sources, duplicate topics, an off-brand hook. Those repairs were the procedure nobody had written down yet, and they became the first draft of the skill.

We scoped it to one sentence: take what we already know — offers, pages, proof, voice, and messy notes — and return a review-ready content plan for the next cycle. Not “write 30 blog posts.” Not a replacement for the strategist. A plan the lead could accept, reject, or send back with the gaps still showing.

That precision is what makes a job buildable and, just as importantly, what makes it quotable. The four filters we apply before committing to any build are in how to choose the first process to turn into an AI workflow, and a recurring planning cycle clears all four comfortably: it repeats, the output is reviewable in minutes, a strong marketer already has a method, and inconsistency costs real rework.

The engagement bought one workflow: discovery with the person who already planned well, a definition of done agreed with their reviewer, the skill itself with its references and templates, a test suite built from their own files, install notes for the tools they used, and a named owner on their side. That is the whole scope, and holding it there is why the number was three thousand rather than thirty.

What it did not cover is equally deliberate. No knowledge-base cleanup project, no second workflow bolted on mid-build, no integration work, no publishing pipeline. Teams routinely try to widen a first engagement into a transformation programme, and the result is that nothing ships. One job, one team, one reviewer is the constraint that makes a first build finishable — the reasoning is in constraining the first build.

The workflow is time-triggered, and the cadence differs by channel: weekly for social and lifecycle, monthly for the blog and campaigns. Naming the trigger mattered because it decides what the workflow does with missing input — a weekly run proceeds and reports the absence rather than waiting for a complete set.

Trigger design is part of discovery rather than an implementation detail. The full four-stage mapping method is in turning a team SOP into a reusable AI workflow.

We catalogued what the team genuinely had on hand, not what a tidy process would have had. This is the step most planning projects skip, and it is why so many of them stall waiting for a documentation cleanup that never finishes.

Each input was marked required or optional, with a stated reliability. Old briefs are rich and frequently out of date; the knowledge base is current but incomplete; sales notes are the most honest source of customer language and the least structured.

Three decisions were fenced off from the start: final theme priority, anything that sounded like a promise, price, or guarantee, and anything that would reach a customer without a reviewer. The workflow could draft a recommendation on all three; it could not settle any of them.

Writing those boundaries as rules with a named destination — rather than as a general instruction to be careful — is what makes them hold under deadline pressure, as covered in boundaries, escalation rules, and approval points.

A plan was finished when it contained five things, in the same order every cycle. This is the single most important artifact of the engagement: without it, “good plan” is a matter of taste and no two runs are comparable.

Note that the fifth item makes an incomplete plan a passing plan. A run that surfaces two unanswerable questions has done its job better than one that quietly fills them in.

If a source was missing, the workflow had to leave the hole visible. It was not allowed to invent a campaign to look complete, and it was not allowed to let a missing performance sheet quietly weaken a recommendation elsewhere in the plan.

This unknowns policy is the rule that does the most work in any planning workflow, because the default behaviour of a language model is to produce a plausible, complete-looking answer. Naming required and optional inputs up front — and saying what happens when one is absent — is the practice described in input contracts for messy notes and files.

The operator drops in the knowledge-base export or links, plus the messy extras: notes, a previous calendar, a sales thread, a performance sheet. The skill then lists what it received, by name, before it plans anything.

Unnamed paste-dumps get flagged rather than absorbed. That single behaviour removes a whole class of quiet failure, because a claim can only be traced later if the source it came from was named at intake.

The skill reads internal sources first and treats public research as optional and secondary. If the knowledge base already has a page on a topic, the plan has to say so. If sales notes keep repeating an objection, the plan has to show that objection as evidence rather than assert it as a theme.

This is the difference between a plan about your company and a plan about your category. Generic output is almost always a sourcing problem rather than a model problem — the same evidence discipline applied to research is in forcing citations to named sources.

Same structure every cycle, claims pointing back to inputs, unknowns left unknown, and every required section present — even when the honest content of a section is “we do not have data for this.”

Review-ready is a higher bar than “a good starting point,” and it is the bar worth holding. Designing the review so a lead can work through a plan in minutes rather than rebuilding it is its own discipline, covered in designing a three-minute review.

Each line of the slate carried seven fields. The fields are what make a plan reviewable at speed: a lead can scan the source column and the risk column and know immediately which three items need their attention.

Specifying the item shape this tightly is also what stops two runs of the same workflow looking nothing alike, which is the most common complaint about AI-assisted planning.

The plan had to include what it considered and rejected, with reasons. A planning workflow that only says “yes” is an idea generator, and idea generators are exactly what this team already had too many of.

The rejected list is also where the workflow earned trust fastest. A lead who sees their own reasoning reflected back — “not recommending a comparison page this cycle because the positioning page is still out of date” — stops auditing every line and starts reviewing the exceptions.

We did not ask the team to tidy anything first. The workflow was designed for the state their files were actually in, which is the only version of the project that ever ships — and the only version that fits inside a compact engagement.

The distinction that made this tractable is that a wiki stores what is true, an SOP describes how work is done, and a skill runs a checked version of a job. Deciding which of their material belonged in which place was part of discovery — see wiki, SOP, or runnable skill.

Every source class got an explicit permission and an explicit prohibition. Without the prohibition half, a workflow allowed to read “company documents” will eventually cite something two years stale and present it as current strategy.

The prohibitions are the more important column, and they are the ones teams forget to write. Each of these was tested directly rather than assumed.

Their sources disagreed constantly. An old brief promised a feature the current knowledge base no longer listed; a spreadsheet said a topic underperformed while a sales thread said customers kept asking for it. The workflow had to surface the disagreement and escalate it, never silently pick a winner.

That behaviour is the clearest line between a workflow and a prompt that just writes something. A prompt resolves the conflict invisibly and confidently; a workflow hands the conflict to the person who is allowed to settle it.

Banned phrases, required disclaimers, and claim restrictions were treated as hard constraints rather than preferences, and the workflow was explicitly forbidden from rewording a restriction to make a headline land better.

Restricting the source set this way is a quality control as much as a compliance one — it bounds what can be asserted and stops unverifiable claims entering a document that feeds real publishing decisions. The wider control set is in allowed sources and least-privilege connections.

Before the team relied on it, we ran three case types built from their own history. The typical case was the current knowledge base plus last month’s calendar and one sales thread. The messy case was a partial export, three conflicting decks, and no performance sheet. The edge case was a campaign week with a new offer that was barely documented anywhere.

The messy case is the one that changed the workflow most, because it is the one that forced the unknowns policy to do visible work. The method for assembling a suite like this from real history is in ugly-input testing before launch.

Runs were scored against binary checks rather than read for impression. A run passed only if it passed every one of them; anything softer turns a test suite into a formality.

The last check is the one that catches the failure mode nobody expects. A plan that ignores the existing library in order to look fresh is worse than no plan, because it quietly manufactures duplicate content.

We are not publishing this client’s numbers, so take the following as described rather than measured. Their marketing lead stopped starting from a blank page. Planners stopped rebuilding the same context pack every cycle. A new teammate could run the job without inheriting a private prompt from somebody’s Slack history.

Practically: context assembly became a checklist rather than a scavenger hunt, plans arrived in a structure reviewers already recognised, refresh-versus-new became an explicit decision that cut duplicate work, and sales language and knowledge-base language finally showed up in the same document. Review time moved to judgment — priority, timing, risk — instead of reconstruction. Which of those effects are worth putting in front of an economic buyer, and how to baseline them honestly, is covered in building an ROI case that survives scrutiny.

Content planning is a good workflow. Unsupervised publishing is not. The skill does not publish posts, invent case studies or metrics or customer quotes, override brand and legal restrictions, pretend the knowledge base is complete, or replace the lead’s priority call.

Sensitive lines — pricing, guarantees, partnership claims, anything going out in the company’s voice — hit an approval point. The plan can draft the recommendation; a human still owns the send. Autonomy is earned per category on logged evidence, never granted because a demo went well.

If planning at your company still depends on whoever remembers where the docs are, the constraint is not model capability. It is that the job has never been written down. Four signals say a planning cycle is ready to be packaged.

You do not need a finished knowledge graph to start. You need named sources, a definition of done, and tests that include the ugly inputs you actually have.

They got a versioned skill they could run in the agents they already used — ChatGPT, Claude, Gemini, Grok, or Cursor — without rebuilding the process per tool, which is the portability argument in one skill, five tools. It shipped with the test suite, the definition of done agreed with their reviewer, and a named owner on their side, so the next process change is a version bump rather than a rebuild — see what a version bump should carry.

Three thousand dollars bought one repeated job done properly, not a platform. Whether your version needs a custom build at all depends on how much of it is specific to you; the decision test is in what to install and what to commission, and the build-it-yourself alternative is weighed on custom workflow versus building in house. Bring us the repeated cycle and the sources you already have — the stages are on the custom workflows page, the worked examples show finished output shapes, and you can discuss your planning cycle directly.