A useful blog post needs more than a topic and a prompt. The AI needs to know who the article is for, what it should accomplish, how it should be structured, which keyword anchors it, and what source material it can trust. More importantly, it needs the experience, examples, opinions, and case studies that only you can provide.
This playbook shows you how to build a workflow that separates those jobs instead of asking the AI to solve everything in one pass. The screenshots and field names come from the Coordination Zero OS reference build. Your version can live in Airtable, Notion, Sheets, Supabase, or a custom application. It does not need to look the same. It needs to preserve the same records, context, checkpoints, and handoffs.
Your build begins with a place to store one record for every blog post. Each time you run the workflow, you select the Brand, intended audience, content goal, article type, writing tone, keyword, and any available research or source material. Your prompt or automation uses that context to generate two things at the same time: a proposed outline and a set of clarifying questions.
The outline gives the article its structure. The questions give you a deliberate place to add the material the AI cannot know on its own: what you have tried, what happened, what failed, what changed, what clients have experienced, and what you actually believe about the topic.
Only after that context is captured do you generate the draft.
- Brand records: the default voice, positioning, language rules, and business context
- Persona records: the complete audience profiles you will pass into generation
- A working database: Airtable, Notion, Sheets, Supabase, or another place where the blog record and its linked context can live
- An AI tool: the model you will use manually or connect through an automation
Each blog post needs a selected Blog Post Prompt, one primary keyword, and source notes or a transcript. A format-specific Style Guide, linked Research, originating Idea, supporting keywords, and supplied links are optional layers you can add when available.
Details
Complete the article brief, context, keywords, links, and source material.
Outline
Review, edit, regenerate, or approve the proposed article structure.
Questions
Add firsthand experience, examples, case studies, results, and opinions.
Draft
Generate from the complete brief, current outline, and saved answers.
Publish
Create the metadata and move the approved article into the publishing system.
The clarifying questions are optional. The knowledge they collect is not. You can skip the questions and generate a draft immediately, but you should expect considerably more editing. When the AI reaches a section that calls for a real example or specific experience and you have not supplied one, it can only stay generic or invent something plausible. Neither produces an article worth publishing.
Brief answers are enough. A rough story, failed experiment, customer objection, or a few sentences explaining your position gives the AI material it can develop without pretending it knows your history.
Do not ask the AI to invent authority. Give it the structure, then add the experience that makes the article yours.
A reusable Blog Post table, record structure, and generation workflow you can run for every article. Each finished record holds the complete production history and remains the source of truth after publication.
Start with one place to store every blog post. If your operating system already has a general Content table, add Blog Post as a content type and add the fields below. If it does not, create a dedicated Blog Posts table.
One row or record should follow the article from the first working title through outline, questions, draft, approval, and publication. Do not create separate disconnected documents for each stage. The value of the workflow comes from keeping the original direction, human answers, generated work, and publishing details together.
The field names can change to match your tools. The jobs those fields perform should not.
Create the table and required fields first. Run the generation steps manually in your AI tool and paste the results back into the record. Once the workflow produces reliable articles, connect the same fields through Make, Zapier, n8n, or your own application.
Input fields hold the direction you provide. Generated fields hold the outline, questions, draft, and metadata the workflow creates later. Keeping both on the same record makes regeneration predictable and preserves the article's history.
The internal starting title or topic direction. It does not need to be the final headline; the outline and draft can improve it later.
Connect the article to the Brand record containing its voice, positioning, excluded language, business context, and default writing rules.
The person whose name and point of view the article represents. This matters when a company publishes work from multiple founders, experts, or client voices.
The saved prompt that defines the article type and structure: how-to, listicle, case study, comparison, thought leadership, or another format you regularly publish. Filter this field to active Blog Post prompts.
How this article should sound inside the selected structure. The tone adjusts the delivery; it does not replace the Brand voice or determine the article type.
The model used for outline and draft generation. Store it on the record so you can trace output differences and change models without rebuilding the workflow.
The specific Persona this article is written for. Pass the full Persona profile into generation, not only its name.
The business outcome the article should support. The goal guides emphasis and the call to action without turning every article into sales copy.
A format-specific guide built from real examples of how this Brand writes this kind of blog post. If no Style Guide is selected, fall back to the broader Brand voice.
A Research record that informed the article. Pass its useful source material and analysis into generation instead of relying on the AI to reconstruct it.
The idea, observation, request, or planning record that started the article. This preserves the connection between planning and production.
Use one primary keyword or search phrase. It anchors the headline, H1, article direction, and meta description. Do not ask the workflow to rank one article for five unrelated primary terms.
Secondary terms, related questions, and natural variations that support the primary keyword.
Existing pages, articles, offers, or resources on your own site that should be linked when relevant.
Original sources, references, research, or supporting material the article may cite. Supplying the link does not remove the need to verify the claim.
The offer, product, booking page, or disclosed affiliate destination the article may support when it fits the selected goal.
The raw material the AI builds from: your angle, key points, hook ideas, transcript excerpts, factual notes, non-negotiable claims, and anything the finished article must include.
The proposed title, introduction direction, headings, section purpose, and conclusion path. Store the edited version, because this is what the draft-generation step should read.
Up to five focused questions and the author's saved answers. The simplest build stores the pairs in one structured field. A more advanced build can use related Question records with Question, Answer, Order, and Blog Post fields.
The article generated from the current brief, outline, and saved answers. Keep it on the parent record so edits and regeneration never lose the source context.
The search description created after the draft is approved. Keep a visible character count in your interface when possible.
A short summary for archive pages, previews, feeds, or the destination CMS.
The URL-safe path for the article. Review it before publishing; changing a slug after publication can break links unless redirects are configured.
The final public destination. Save it back to the record so downstream emails, social posts, guest assets, and tasks all use the same link.
An estimate calculated from the approved word count. This can be generated by the workflow or calculated with a formula.
Use statuses that match your real approval path. At minimum: In Progress, Approved, Scheduled, Published, and Archived. Teams can add Needs Review or Revisions when those states represent actual handoffs.
The planned or actual publication time. This field can feed the shared working calendar and trigger a publishing automation.
The destination site's editorial category or taxonomy. Keep this aligned with the CMS instead of creating a second unrelated category system.
Writing Tone examples
Analytical, Case Study / Example-Based, Contrarian, Conversational, Educational / Explainer, Inspirational, Instructional, List-Based, News / Trend, Persuasive, and Storytelling.
Content Goal examples
Appointment Booking, Consultation Request, Drive Product Trials, Drive Sales / Revenue, Generate Leads, Increase Brand Awareness, Product Purchase, Support Customer Retention, and Thought Leadership.
You do not need to reproduce these dropdown values exactly. Use the tones and goals your business actually needs. The important part is that every article makes an explicit audience, structure, tone, goal, and keyword decision before generation begins.
Use this prompt once to turn the field map into a table, form, and working views in your chosen tool. The generation prompt belongs to the next stage, after a form submission has created the Blog Post record.
Show the full prompt
I want to build a reusable Blog Post workflow in [AIRTABLE / NOTION / GOOGLE SHEETS / SUPABASE / MY OWN APP]. Help me create the database structure. I am building my own operating system, not recreating a specific interface.
Create one Blog Posts table. One record must follow an article from the initial brief through outline, clarifying questions, draft, approval, and publication.
INPUT FIELDS
- Working Title — single-line text, required
- Brand — linked Brand record, required
- Author — person or text, required
- Blog Post Prompt — linked Prompt record filtered to active Blog Post prompts, required
- Writing Tone — single select, required
- AI Tool to Use — single select, recommended
- Intended Audience — linked Persona record, required
- Content Goal — single select, required
- Style Guide — linked record, optional
- Research — linked record, optional
- Originating Idea — linked record, optional
- Primary Keyword — single-line text, required; allow one primary keyword only
- Supporting Keywords — long text or multi-value, optional
- Internal Links — URL list, optional
- External Links — URL list, optional
- Offer / Affiliate Links — URL list, optional
- Source Notes / Transcript — long text, required
GENERATED AND EDITABLE FIELDS
- Outline — long text or structured content
- Clarifying Questions & Answers — structured text or related records; allow no more than five questions
- Working Draft — rich text or long text
- Meta Description — long text
- Excerpt — long text
- Website URL Slug — single-line text
- Blog Post URL — URL
- Reading Time — calculated number or text
WORKFLOW FIELDS
- Status — single select with In Progress, Approved, Scheduled, Published, and Archived; add Needs Review or Revisions only if the workflow needs them
- Scheduled / Published Date — date and time
- Blog Category — single or multi-select aligned with the destination CMS
Then show me:
1. The final table schema with the best field type for this tool
2. Which linked tables must already exist
3. A form or record layout grouped into About the Post, Audience and Angle, Source Material, Generated Work, and Publishing
4. A working view for articles in progress
5. A review view for articles awaiting approval
6. A calendar view using the scheduled or published date
7. How to preserve the edited outline and saved answers when the draft is regenerated
Do not build the social, email, video, image, or task workflows yet. Leave relationships available so those shared Content Stack workflows can connect to the approved Blog Post record later.You have one Blog Post record that can store the setup fields, linked context, generated outline, clarifying answers, draft, and publishing details without overwriting earlier work.
This stage turns a completed Blog Post record into two saved outputs: an editable outline and up to five clarifying questions.
The questions are designed to uncover the author’s real experience, examples, process, results, failures, and opinions before the article is written. They are optional, but skipping them usually creates more editing because the draft has less firsthand material to work with.
Use the fields and linked records already created in Section 01. Do not create a second context table or copy the same field definitions into this stage.
When this stage is complete, the Blog Post record contains a reviewed outline and any saved answers. Both remain editable and are retrieved later when the user generates the draft.
Native trigger
Use your database tool’s “when a form is submitted” or “when a record is created” trigger. Pass the new Blog Post record ID into the next action.
Webhook trigger
Send the successful form submission to Make, Zapier, n8n, or your own endpoint. Include the saved Blog Post record ID so the automation can retrieve the record.
Manual fallback
If your form cannot start an automation, create a view of records with an empty Outline field and run the workflow from a button or scheduled check.
Start automatically after a successful form submission. Use the saved record ID as the handoff—not the temporary form payload. The automation should reopen the record and retrieve its linked records before it calls the AI.
1. Create the record
The form writes the user’s selections and source material into a new Blog Post record. The database returns the unique ID for that saved record.
2. Start once
The successful submission sends that record ID to the automation. Add a condition that the Outline field must still be empty so retries do not create duplicate work.
3. Retrieve the context
Reopen the Blog Post record, then retrieve the full selected Brand, Persona, Blog Post Prompt, Style Guide, and Research records. A form usually stores their IDs or names—not their complete contents.
4. Validate
Confirm the required fields from Section 01 are present. If something is missing, stop the run and return the record for completion instead of asking the AI to fill the gap.
5. Generate
Map the retrieved values into Prompt 02 and send it to the selected AI model. Request one structured response containing the outline and no more than five questions.
6. Parse the response
Separate the proposed title, outline, and question set. If your tool supports structured JSON output, use it; otherwise split the labeled sections returned by the prompt.
7. Update the record
Write the proposed title and outline to the Outline field and write the questions to their own field or related records. Keep the Blog Post status In Progress.
8. Hand off for review
Open the saved record or notify the user that the outline is ready. The user can edit the outline, change a question, add answers, or skip the questions before generating the draft.
Show the trigger and action map
TRIGGER
Event: Blog Post setup form submitted successfully
Input: {{blog_post_record_id}}
RUN CONDITIONS
- The Blog Post record exists
- Required setup fields are present
- Outline is empty
ACTIONS
1. Retrieve the Blog Post record by ID
2. Retrieve the full linked Brand record
3. Retrieve the full linked Persona record
4. Retrieve the selected Blog Post Prompt
5. Retrieve the Style Guide and Research when selected
6. Map those values and the Blog Post fields into Prompt 02
7. Send Prompt 02 to the selected AI model
8. Parse Proposed Title, Outline, and Clarifying Questions
9. Save Outline and Clarifying Questions separately on the same Blog Post record
10. Notify the user or place the record in an Outline Ready review view
ON FAILURE
- Do not write a partial outline over existing work
- Log the failed step and error returned
- Keep the record available for correction and a manual retryShow the full prompt
You are helping me plan a blog post. Create the outline and the clarifying questions in the same response. Do not write the article yet.
ARTICLE DETAILS
Working title: {{working_title}}
Author: {{author}}
Content goal: {{content_goal}}
Writing tone: {{writing_tone}}
Primary keyword: {{primary_keyword}}
Supporting keywords: {{supporting_keywords}}
Internal links: {{internal_links}}
External links: {{external_links}}
Offer or affiliate links: {{offer_links}}
LINKED CONTEXT
Brand voice and business context: {{brand_context}}
Intended audience Persona: {{persona_context}}
Selected Blog Post Prompt: {{blog_post_prompt}}
Format-specific Style Guide, if selected: {{style_guide}}
Linked Research, if selected: {{research}}
Source notes or transcript: {{source_notes}}
INSTRUCTIONS
1. Use the selected Blog Post Prompt to determine the article type and structure.
2. Use the Style Guide for format-specific writing patterns when one is provided. If it is blank, use the Brand voice as the writing default.
3. Use the Persona to decide what the reader already knows, what needs explaining, and which problems or outcomes matter most.
4. Build a useful outline with a proposed final title, introduction direction, H2 and H3 sections, the purpose of each section, and a conclusion or next step aligned with the Content Goal.
5. Use the primary keyword naturally in the proposed title, H1 direction, and appropriate sections. Use supporting keywords only where relevant.
6. Do not invent personal experience, client examples, case studies, results, quotes, statistics, or factual claims.
7. After the outline, identify only the missing firsthand knowledge that would make the article more accurate, original, or useful.
8. Ask no more than five clarifying questions. Ask fewer when the source material already provides enough firsthand context.
9. Tie every question to a specific section or gap in the outline. Prioritize real experience, examples, processes, outcomes, failures, objections, and the author's actual point of view.
10. Do not ask for information already present in the supplied context. Do not ask generic questions that will not materially change the draft.
RETURN EXACTLY
PROPOSED TITLE
[One title]
OUTLINE
[Introduction direction]
[H2 and H3 structure, with one or two sentences explaining what each section must accomplish]
[Conclusion or next-step direction]
CLARIFYING QUESTIONS
Q1. [Question]
Used in: [outline section]
Why it matters: [the gap this answer will fill]
[Repeat only as needed, never exceeding five questions. If no questions are needed, say: "The supplied context is sufficient to draft without additional questions."]
STOP after the questions. Do not draft the article.Write the outline into the Outline field and the question-and-answer pairs into their own field or related records. Do not store the entire AI response as one undifferentiated block. The draft workflow needs to retrieve the current edited outline and the saved answers independently.
The user has reviewed the outline, answered any questions that will materially improve the article, and is ready to generate the first draft from those saved records.