ghostMarketingFlow

A content and email marketing playbook for Ghost: methodology plus an executable plugin.

The intent: take a small audience and move them across awareness → consideration → decision using Ghost's content and email surface. For the day-two operator who needs reads to convert into conversations, not just impressions into likes.

Built in public. The site you are on is part of the live demonstration.

knowledge-base files

Each framework idea drops one file into knowledge-base/. These are the real files for ghostMarketingFlow, building up across the framework. Each links back to the idea that produces it.

user.md

A methodology the operator runs for themselves, triggered by upcoming events like a workshop or launch. The user IS the operator. Use this shape if you are building internal tooling or a playbook for your own work.

# knowledge-base/user.md

User: A small-community founder publishing on Ghost whose newsletter is the front door to paid work (workshops, 1:1s, cohorts)

Trigger: A workshop or launch is coming up and the operator runs the playbook's post and email sequence across awareness, consideration and decision

Outcome: The right post and email land in the right order with reader replies and workshop signups landing in the operator's inbox

From 1.1.1, If You Can't Name the User, You're Guessing What They Want.

problem.md

A pain about pipeline: work that does not convert into the conversations or signups it was meant to fill. The user is the operator and the pain hits their calendar, not their wallet. Use this shape if the pain you are naming is about a funnel that leaks.

# knowledge-base/problem.md

Pain: The newsletter goes out and readers stay readers; not enough convert to workshop signups or 1:1 calls

Trigger: A workshop slot is approaching and the founder realises the last few sends have not built any momentum toward filling it

Cost: A workshop runs at half-capacity or gets cancelled; the founder's calendar stays empty when it could be paid work

From 1.1.2, Describe the Pain Without Mentioning the Solution.

promise.md

A promise framed around a repeatable workflow the operator runs themselves, with concrete signals at each funnel stage. Boundaries protect against scope creep into work the user prefers to keep personal. Use this shape if the operator IS the user and wants methodology, not automation.

# knowledge-base/promise.md

User: A small-community founder publishing on Ghost whose newsletter is the front door to paid work (workshops, 1:1s, cohorts)

Promised outcome: A repeatable post and email sequence that moves readers across awareness, consideration and decision, with concrete signals at each stage so the founder knows what is working

Boundary: Does not run paid ads, does not chase mass audience growth and does not automate the personal back-and-forth that turns interest into a paid engagement

From 1.1.3, The One-Line Promise That Keeps Your Build Honest Throughout.

positioning.md

Positioning aimed at the operator running their own marketing. The useful result is a method, not a thing delivered. Use this shape if your product is the methodology your user runs.

# knowledge-base/positioning.md

User: A small-community founder publishing on Ghost whose paid offerings (workshops, 1:1s, cohorts) need filling

Problem: The newsletter goes out but reads do not turn into bookings; there is no repeatable sequence from publish to paid

Useful result: A documented post-and-email sequence the founder runs themselves across awareness, consideration and decision, with concrete signals at each stage

From 1.2.1, Can You Explain This in 30 Seconds Without Mentioning the Tech?.

success.md

Success measured in pipeline outcome: did the sequence fill the slots. Use this shape if the operator's reward is downstream of the methodology working, not the methodology itself.

# knowledge-base/success.md

Outcome: The post-and-email sequence consistently fills upcoming workshop and 1:1 slots before they go stale

Metric: Percentage of workshop slots filled within two weeks of the trigger send

Threshold: 70% slot-fill rate across the first 10 workshop cycles before scaling cadence or scope

From 1.2.2, What Does "Success" Actually Mean for the First Version You Ship?.

risks.md

A risk about funnel mechanics: activity does not equal conversion. Use this shape if your value chain has multiple stages, any one of which can break without the others looking different.

# knowledge-base/risks.md

Likely failure: The awareness, consideration and decision sequence produces lots of newsletter activity but the conversion to a paid booking never materialises, so the founder keeps publishing into a leaky funnel

Affected user or workflow: The small-community founder relying on the playbook to fill workshops; if the funnel leaks at decision stage, the methodology fails its core promise

Mitigation: Track booking conversion per send, not just opens; if conversion is low, change the decision-stage call-to-action or shorten the consideration window before declaring the sequence broken

From 1.2.3, The Risks You're Avoiding Naming Are the Ones That Bite You.

goal.md

A goal about sustaining a practice (filling the calendar). Use this shape if your product's value is about making someone's work life viable on cadence, not about a single transaction.

# knowledge-base/goal.md

User outcome: Founders move from "publishing into a void" to "running a small repeatable engine that fills paid offerings on cadence"

Why it matters: Small communities depend on the founder's calendar being full of paid work; a methodology that reliably fills slots is the difference between sustainable practice and burnout

Proof signal: Each scheduled workshop fills past threshold without ad spend and at least one reader per cycle moves from newsletter subscriber to paid engagement

From 1.3.1, The One Outcome That Makes This Build Worth Doing in the First Place.

scope.md

Cuts that protect against scaling out of the audience and tone that give the methodology its value. Use this shape if your value depends on a particular size or relationship with the user.

# knowledge-base/scope.md

Keep in: The post-and-email sequence across awareness, consideration and decision; recipes for triggering the sequence from upcoming events; signal-tracking at each stage

Leave out: Paid acquisition (ads, SEO tooling), mass-audience growth tactics and automated message-thread or sales engagement

Why the cut helps: The whole methodology assumes a small community where the founder still does the personal back-and-forth; chasing scale or automating the conversation turns the playbook into something else entirely

From 1.3.2, What This Will Not Do (On Purpose) Is Half the Decision.

path.md

A path inside a campaign window (event trigger, sequence, conversion). Use this shape if your product is run as a campaign with a deadline rather than as ongoing daily use.

# knowledge-base/path.md

User: A small-community founder with a Ghost publication and an upcoming workshop slot to fill

Trigger: The workshop slot is 3-4 weeks away and the founder opens the playbook to run the sequence

Path to outcome: Send the awareness post, send the consideration follow-up email, send the decision post with the workshop link, track replies and signups, hand-write to any high-signal reader who has not booked, close the workshop fill

From 1.3.3, Describe One Main Path First, Then Ignore Everything Else.

build/prototype-path.md

A prototype path that tests a multi-stage funnel under real conditions. Use this shape if your build is a sequence whose value only appears at the end of the chain.

# knowledge-base/build/prototype-path.md

Learning goal: Whether the post-and-email sequence actually moves a reader from awareness to a paid booking, or just produces engagement that does not convert

Path to test: Publish one full awareness, consideration and decision sequence for a single workshop, and track who reads each piece and who books

Proof signal: At least two unique readers move through all three stages and book the workshop, vs the founder's prior rate of zero from direct newsletter

From 2.1.1, The Only Path Your Prototype Actually Needs to Walk.

build/value-moment.md

A value moment in causality (publish, then directly observe results). Use this shape if your product's wedge is closing a feedback loop the user has been operating without.

# knowledge-base/build/value-moment.md

User: A small-community founder who has been publishing on Ghost for a while but has never run a deliberate sequence

First value moment: The moment they send the decision-stage post and see direct replies and bookings come in within hours, not weeks

Step that gets them there: A single end-to-end sequence template they can copy and fill in, so the first run lands as a working artifact, not a planning exercise

From 2.1.2, Where the User First Feels Value Is Where to Start Building.

build/learning-goal.md

A hypothesis about content strategy at funnel stages. Use this shape if the build's central bet is about how to frame the moves you make at each stage.

# knowledge-base/build/learning-goal.md

Hypothesis: A small community will move from reader to paid booking more reliably when the sequence makes the value of the paid offering explicit at decision stage, rather than implicit across the whole newsletter

Question: Does naming the workshop, the price and the outcome directly at decision stage produce more bookings than seeding them subtly across the consideration stage

Signal that answers it: Decision-stage explicit posts convert at a higher booking rate than equivalent subtle-seeding posts across at least three workshop cycles

From 2.1.3, What This Build Is Meant to Teach You, Not Just to Ship.

build/routine-checklist.md

Routine work that is multi-step and sequenced; drift at any stage breaks the chain. Use this shape if your routine work is a sequenced pipeline where each step depends on the previous one being correct.

# knowledge-base/build/routine-checklist.md

Recurring task: Before each workshop cycle, queue the awareness, consideration and decision posts in Ghost and confirm the email-segment targeting on each one matches the funnel stage

Owner: The founder during early cycles, since miss-segmented sends or missing decision posts kill the funnel before subtler tuning matters

Done condition: A dry-run preview of each scheduled send lands in the founder's own member account in the right order, with stage-appropriate copy and the correct cal.com link

From 2.2.1, The Routine Work Checklist Nobody Talks About.

build/buy-vs-build.md

A buy decision that recognises an established commodity layer (newsletter scheduling) sits under your differentiated layer (the sequence design). Use this shape if your value sits above a mature platform.

# knowledge-base/build/buy-vs-build.md

Decision area: Whether to build a custom email-sequence orchestrator or use Ghost's built-in newsletter scheduling plus Resend for transactional sends

Reason to buy or build: Buy it through Ghost and Resend, because newsletter scheduling, member segmentation and deliverability are mature problems that any custom build would only partially solve

Deciding constraint: The product is the methodology, not the orchestrator; the value is in the sequence design and the bridge to bookings, not in re-implementing scheduled-send tools that already work

From 2.2.2, Buy vs Build Is a Strategy Choice, Not an Engineering One.

build/system-shape.md

A shape that integrates with a mature platform (Ghost) where the platform owns delivery and your layer owns sequencing. Use this shape if your differentiator sits on top of someone else's mature infrastructure.

# knowledge-base/build/system-shape.md

Boundary: The methodology docs own what to write at each stage and when; the flowRun plugin owns which scheduled sends to queue and how to track signal at each stage; Ghost owns the actual publish-and-send

Dependency: The plugin depends on the Ghost Admin API for publishing and member segments; on Resend for any non-Ghost transactional sends; on the founder's cal.com for booking links

Handoff: The plugin queues the publish, Ghost owns delivery, the founder owns any personal back-and-forth that follows a high-signal reply, the plugin re-takes control to mark the cycle done

From 2.2.3, Understanding the Shape of the System Before You Change It.

build/differentiation.md

Differentiation in the assumptions the methodology makes about scale and relationship. Use this shape if your edge is design choices that fit a specific kind of user the alternatives ignore.

# knowledge-base/build/differentiation.md

Real advantage: The methodology was designed by a small-community founder for small-community founders, so the funnel cadence and tone assume relationships over transactions and personal back-and-forth as a feature, not friction

Where it shows up: In how the consideration-stage emails make personal-reply implicit and the decision-stage post leaves room for the founder to hand-write to any high-signal reader who has not booked

What stays standard: Publishing, scheduling, member segmentation and email delivery stay on Ghost and Resend, since differentiating those would dilute the methodology

From 2.3.1, Where the Real Differentiation Actually Lives in Your Build.

build/not-in-v1.md

A cut that protects the methodology's core relational nature against being automated away. Use this shape if your v1 risk is automation that removes the user's own attention.

# knowledge-base/build/not-in-v1.md

Core path: Publish the awareness post, send the consideration email, send the decision post, track conversion, close the cycle

Feature to cut: An automated drip series with branching based on click behaviour, tempting for v1 but tipping the methodology from sequenced campaigns into always-on marketing automation

Why the cut strengthens it: Branching drips remove the founder's own attention from the conversation, which is the very thing that makes the methodology work; v1 keeps the founder in the loop so personal replies remain the differentiator

From 2.3.2, Why Cutting Features Is a Design Skill Most Builders Skip.

build/proof-metric.md

A metric on the funnel converting through to the paid event. Use this shape if your value chain spans multiple stages and the only one that matters is the last.

# knowledge-base/build/proof-metric.md

Metric: Bookings per workshop cycle attributable to the sequence (not paid traffic or referral)

User behaviour: A reader moving through awareness, consideration and decision sends, then booking the workshop via the in-post link

Threshold: Seven workshop bookings per cycle directly from sequence sends across three consecutive cycles before optimising any single stage

From 2.3.3, The One Metric That Proves This Works for Real Users.

launch/sharing-plan.md

An audience that would adopt the methodology, shown the choices that produced the result. Use this shape if your product is a methodology and peer adoption is the goal.

# knowledge-base/launch/sharing-plan.md

Audience: Two or three other small-community founders who already run their own Ghost publication and have the same fill-the-calendar problem

What to show: One real sequence run end-to-end against the founder's own audience, with the post drafts and the email copy shared in advance so the other founders can see the choices, not just the results

Question to answer: Whether the sequence design makes sense to peers who would adopt the methodology, not whether it produced a single win

From 3.1.1, Why Sharing Early Creates the Learning Your Build Needs.

launch/decision-signal.md

A signal read from funnel-stage movement (consideration to decision). Use this shape if your signal is progression through a known multi-step funnel.

# knowledge-base/launch/decision-signal.md

Observable signal: Whether readers move from "open the consideration email" to "click the decision post link" within a defined window

Behaviour behind it: A reader graduating from interested to ready-to-book, which is the conversion the sequence exists to engineer

Decision it changes: Whether the consideration-to-decision gap is right, or whether the gap is too long (readers cool off) or too short (readers feel rushed)

From 3.1.2, Ask for Signals, Not Opinions, From the People You Trust.

launch/decision-threshold.md

A threshold for funnel-conversion at the paid stage. Use this shape if your launch hinges on a sequence reliably producing transactions.

# knowledge-base/launch/decision-threshold.md

Threshold: If three consecutive workshop cycles each produce fewer than three bookings directly from the sequence, the decision-stage copy or the offer itself is the problem, not the consideration setup

Evidence source: Booking-attribution counts per cycle from the Ghost member list against the cal.com booking timestamps

Action if met: Hold the methodology rollout to other founders and rework the decision-stage prompt and pricing before recommending the sequence as a whole

From 3.1.3, Decide in Advance What Would Change Your Mind.

launch/learning-signal.md

A diagnostic question that separates a content problem from an audience-fit problem by comparing across topics. Use this shape if your failure mode has both a what and a who cause.

# knowledge-base/launch/learning-signal.md

Question: Are readers dropping out at consideration because the consideration content is weak or because the audience itself is unfamiliar with the workshop subject

Signal that answers it: A consistent drop between awareness and consideration across familiar-topic and unfamiliar-topic cycles points at content; a topic-only drop points at audience fit for that subject

Decision that follows: Rework the consideration copy if the drop is consistent; choose subjects already adjacent to current reader interests if the drop is topic-specific

From 3.2.1, The Difference Between Learning and Being Stuck.

launch/review-context.md

A trade-off between automation and the human-in-the-loop quality of the methodology. Use this shape if your reviewable decision is how much to automate something whose value depends on personal touch.

# knowledge-base/launch/review-context.md

Decision: We run the awareness, consideration and decision sends as scheduled posts and emails rather than a branching drip series triggered by individual reader behaviour

Trade-off: A scheduled sequence loses some personalisation but keeps the founder in the loop on every send, which is the relational quality the methodology is built around

Question for the reviewer: Does the scheduled sequence still meet the conversion bar without the per-reader branching, given the audience is small enough for the founder to still hand-write where it matters

From 3.2.2, Explain Your Decisions Before Asking for Review.

launch/iteration-value-test.md

An iteration that restructures a single conversion point to plug the largest leak. Use this shape if your iteration targets the biggest known leak in a known funnel.

# knowledge-base/launch/iteration-value-test.md

What changed: The decision-stage post moved from a single paragraph linking the cal.com page to a three-paragraph structure that names the outcome, the price and the next available slot

Meant to improve: Conversion from clicked-through-to-the-cal.com-page to actually-booked, which had been the largest leak in the funnel

Signal it worked: Higher booking rates per cal.com page visit, and shorter time between page visit and booking, across the next three cycles

From 3.2.3, Iteration Should Increase Value, Not Just Add Surface Area.

launch/readiness-rule.md

Readiness measured by a peer adopting the methodology successfully. Use this shape if your launch readiness is about replicability across other operators.

# knowledge-base/launch/readiness-rule.md

What has to be true: A new founder can adopt the sequence end-to-end on their own Ghost setup, with the awareness, consideration and decision sends queueing correctly and the booking link landing on a working cal.com page

How it is checked: A founder runs one full cycle on their own audience with the plugin enabled, and the methodology-founder shadows the first cycle to catch surprises

Who owns remaining risk: The methodology-founder signs off the first three cycles run by other founders, then hands off as soon as conversion rates hold without intervention

From 3.3.1, What "Ready" Actually Means Once Real Users Are Looking.

launch/launch-risks.md

A launch risk about a high-leverage single point (the booking link). Use this shape if your launch's biggest risk is one URL or single step that, if broken, kills the whole conversion path.

# knowledge-base/launch/launch-risks.md

This file accumulates one named risk at a time. Each risk follows the
same three-line shape: the likely failure, what triggers it and the
response that is ready before users hit it.

---

## Risk 1: A botched workshop link kills a whole cycle's conversion

Failure mode: The decision-stage post or email contains a broken or wrong cal.com link, and readers who tried to book bounce off instead of recovering

Trigger: A copied-from-staging URL or a renamed event-type slug that the playbook references in multiple places, missed during one of the queue checks

Response: Validate every outbound cal.com link with a HEAD request during the dry-run preview, and ship a single source of truth for the booking URL that the plugin reads from rather than copying into individual posts

From 3.3.2, Name the Risks Yourself Before Users Find Them in Production.

launch/ownership-check.md

An imperfection that the founder's manual work covers. Use this shape if your launch ships an imperfect surface because the user's own follow-up bridges the gap.

# knowledge-base/launch/ownership-check.md

Still imperfect: The sequence treats all readers the same regardless of how engaged they have been historically; a long-time reader and a first-time subscriber both get the same awareness post

If it failed: A long-time reader might feel the awareness post is condescending, like the founder is treating them as a new arrival

Why shipping is acceptable: The founder still hand-writes to known-engaged readers individually after each cycle, so the personal touch survives the bluntness of the scheduled send; segment-aware sequencing depends on data and tooling that v1 deliberately does not include

From 3.3.3, Are You Comfortable Putting Your Name on This Build?.