Guide · automation method
How to write a one-page workflow blueprint
Before we build an automation, it exists on one page. This is that page: seven headings, one worked example from a delivered project, and a blank version you can fill in yourself.
Why one page
A workflow that cannot be described on one page is two workflows, or it is not understood yet. The blueprint forces four decisions that are usually postponed until something breaks: what starts it, which systems it touches, what happens when a step fails, and who approves. It is the same format we produce in the Workflow Workshop and quote from in a build; any builder can execute it, not only us.
The seven headings, filled in for the Visual Engine
The Visual Engine turns a content creator’s 340 reference images into a permanent style and produces on-brand images on a schedule. Here is its blueprint, exactly as the headings would read for your own workflow.
| Heading | Visual Engine (delivered) | What to write |
|---|---|---|
| Trigger | Every day at 07:00 (schedule), or “generate now” from the workspace | The event that starts the run. One trigger per blueprint. |
| Input | Style profile condensed from 340 reference images; today’s theme from the content calendar | What the workflow needs before step one. Name the source system. |
| Steps | 1. Compose prompt from theme + style profile · 2. Generate 1–8 images on GPT Image · 3. Store with date and theme · 4. Post the set to the five connected accounts | Numbered, one verb each. If a step needs a human, write who. |
| Systems | Vyndexo workspace, OpenAI GPT Image, the client’s five social accounts | Every system touched, so licences and access are known up front. |
| Exceptions | Generation fails or style score too low → retry once, then hold the set and notify; account rejects a post → keep the rest, flag the one | What happens when a step fails. Nothing is silently dropped. |
| Approval | None for scheduled sets (the owner pre-approved the themes); on-demand sets are reviewed before posting | Who says yes, and for which runs. “Nobody” is a valid answer if written down. |
| Measure | Sets delivered per day, failed generations, posts rejected | Counted things only. We do not list time saved unless it was measured. |
Blank blueprint to copy
Copy the table into a document. If a cell stays empty after ten minutes, that is the part to talk about first — it is where builds go over budget.
| Heading | Your workflow |
|---|---|
| Name | One line: what it does, for whom |
| Trigger | What starts it: a schedule, a form, an incoming e-mail, a webhook |
| Input | What must exist before step 1, and in which system |
| Steps | 1. … 2. … 3. … 4. — one verb each; name the person if a step is manual |
| Systems | Every tool touched: CRM, mailbox, drive, accounting, chat |
| Exceptions | What happens when a step fails: retry, hold, notify whom |
| Approval | Who says yes, for which runs — “nobody” is fine if written down |
| Measure | Counted things only: runs per week, failures, items handled |
How to pick which workflow to write first
Scoring, not opinion.
Score each recurring task on three numbers: hours per week it costs, how often it runs, and what an error costs when it goes wrong. Multiply. The top three are your first blueprints. This is the scoring we run in the half-day workshop; you can do it yourself with the people who actually do the tasks — the best inventories never come from management alone.
What this page is and is not
The Visual Engine columns describe a delivered project: 340 reference images, one to eight images per scheduled day, five connected accounts. We do not publish time saved for it, because it was not measured. The blank version is a method, not a promise of results. Questions about a specific workflow: describe it in a few lines and we reply with whether it fits one blueprint or several.