Manual Workflow Plan

The Third Delivery Is the Dangerous One

The first manual delivery is discovery. The second may reveal a pattern. By the third, memory starts to impersonate a system. The founder knows which missing field can be inferred, which customer needs a reminder, which script must be rerun, and which claim needs a private check. The customer sees a dependable result. The founder may be the only place where the workflow is dependable.

A manual workflow plan makes that hidden operation inspectable. It follows one promised outcome from an accepted input to the customer behavior that proves delivery mattered. Along the way it records ownership, elapsed time, quality checks, exceptions, recovery, and founder judgment. Repeated runs can then show whether the business is discovering a product rule, operating a valuable service, or hiding a broken process behind personal effort.

Use this plan after a concierge MVP or paid pilot has produced a result worth repeating. It also suits manual onboarding, data cleanup, report generation, review queues, customer setup, and support-heavy delivery. Do not use it to make an unsafe temporary process look official. If the work handles consequential data or decisions, its access, retention, approval, and recovery boundaries must already be honest enough for real use.

Name the Run Before Mapping the Steps

A workflow such as “produce the weekly report” has no useful edge. Does it begin when the customer promises to send data, when a file arrives, or when the founder accepts a complete input? Does it end when a document is uploaded, when the operator reads it, or when the report enters the customer’s real work?

Choose observable boundaries. A run begins when its required inputs pass an acceptance check. It ends when the promised output is delivered, its quality is verified, and the customer’s next action is known. Waiting, reminders, rework, and failures belong inside the record when the founder must carry them.

Bring the customer promise, supported input, quality standard, delivery deadline, support boundary, data-handling terms, and the evidence question that another run should answer. Then copy the plan.

MANUAL WORKFLOW PLAN

DECISION
Customer and recurring job:
Decision these runs must inform:
Current alternative:
Why manual operation is still the right evidence level:

RUN BOUNDARY
Start event and input acceptance check:
Promised output, recipient, and deadline:
Customer behavior that shows the output reached value:
Maximum founder time, open runs, or delivery load:
Conditions that pause or refuse a run:

TRUST AND RECOVERY
Data, access, retention, and deletion boundary:
Customer approval or human review that must remain:
Failure made visible to:
Safe fallback, correction, or recovery path:
Support channel and response boundary:

STEPS — REPEAT THIS BLOCK FOR EACH STEP
Step and trigger:
Owner:
Input and acceptance check:
Action and tools:
Output and definition of done:
Quality check before handoff:
Known failure or stop condition:
Evidence to record, including minutes and judgment:

RUN RECORD — COMPLETE AFTER EACH DELIVERY
Run, customer, and date:
Inputs late, missing, rejected, or repaired:
Minutes by step; waiting time separately:
Rules reused:
Judgments, exceptions, corrections, and rescues:
Output delivered and quality result:
Customer action, repeat request, payment, or abandonment:
Support contacts and unresolved risk:
Change required before another run:

AUTOMATION REVIEW — REVISIT AFTER REAL RUNS
Candidate step:
Repeated input, output, and rule:
Exceptions that still resist the rule:
How success and failure would be detected:
Cost or harm of a wrong result:
Recovery path and manual checkpoint that remain:
Founder burden or customer friction removed:
Decision: automate / assist / template / keep manual / remove:
Evidence that would reopen the decision:

Do not complete the automation review from memory after several weeks. Fill in a run record while the work is recent. Separate active work from waiting: a file that sits overnight does not consume eight founder hours, but a reminder, deadline risk, and blocked delivery still belong in the workflow.

Trace the Work That Actually Happened

Continue the modeled paid-search agency pilot. Its run begins only when the account lead supplies the supported campaign-change export and the required change notes. It ends when the lead confirms that the source-linked review was used to prepare the weekly client report. “Document delivered” is an intermediate state, not proof of value.

The founder maps five steps.

1. Accept the intake. Check the file type, reporting period, client identity, and presence of change notes. Reject or pause incomplete inputs instead of repairing them silently. Record lateness, missing context, and any customer help required.
2. Normalize the evidence. Preserve the source file, parse supported rows, and flag malformed or unmapped data. Record cleanup time and every case the supported format did not cover.
3. Interpret the changes. Compare campaign changes with the account lead’s context and select claims that the supplied evidence can support. Record reused rules separately from judgments that depend on this account.
4. Assemble and review. Put each claim into the agreed digest format, link it to its source, and check totals, dates, unsupported language, and omissions. Uncertain claims are marked or removed; they are not polished into certainty.
5. Deliver and close the run. Send the review through the agreed channel, record corrections and support, and confirm whether the account lead used it. Log founder minutes by step before deciding what should change.

In the first pilot cycle, missing change notes forced three questions and ninety minutes of founder work. That is not merely a slow “interpret” step. It is evidence that the intake contract failed and the founder rescued it. The next run requires a change-note field and a short valid example. With complete inputs, the second review takes forty minutes and the account lead uses it. The plan now preserves the reason for the improvement instead of treating faster delivery as a vague sign that the whole workflow is ready to automate.

Separate Rules from Rescue

After each run, classify what the founder did.

• A reused rule produced the same kind of output from the same kind of input and can be described before seeing the next customer.
• A judgment required context, ambiguity, or a consequence that still deserves human review.
• An exception fell outside the supported path but may reveal a recurring segment need.
• A rescue repaired missing input, a weak promise, confusing instructions, or a failed tool so the customer could still succeed.
• Customer-specific work served one account without strengthening the intended repeatable offer.

These categories prevent the wrong product from forming. A repeated rescue should first change the input contract, promise, or user experience; automating it may only make a design failure faster. A recurring judgment may become a rule after enough comparable cases make its conditions and counterexamples visible. Customer-specific work may deserve a separately priced service, but payment does not turn it into shared product scope.

Variation also needs a name. If the same step changes for every customer, the segment, supported input, or outcome may still be too broad. If one customer repeatedly creates the exceptions while comparable customers follow the same path, the better decision may be to refuse that variation rather than generalize the product around it.

Automate a Boundary, Not a Hope

Repetition alone does not earn automation. A candidate step needs a stable input and output, a rule that survives real cases, a visible failure state, and a recovery path. The founder should also know why removing this labor improves customer value, quality, capacity, risk, or learning. Annoyance is useful evidence, but it is not a specification.

In the agency workflow, file validation and normalization may become a narrow automation candidate once the supported format and rejection states recur. Interpretation remains founder-reviewed while account context still determines which claims are defensible. Source linking may be assisted through a template without automating approval. The workflow can therefore become partly automated without pretending the whole customer outcome has become software.

Risk can move a control forward even when volume is low. A completeness check may deserve code because a missed row would corrupt a client-facing result. The opposite is also true: a frequent step may remain manual when mistakes would be hard to detect or reverse. Write down what happens when the automation is uncertain, unavailable, or wrong before removing the person who currently notices those conditions.

Decide What Kind of Work You Found

Review the plan at a natural cycle boundary, not whenever one run feels unusually easy or painful. Compare customer behavior with founder labor, exceptions, rescues, support, and trust exposure. Then choose one primary change.

• Keep the workflow manual when customers repeat the behavior, the load fits the capacity boundary, and consequential judgment remains part of the value.
• Automate or assist one step when its rule and failure behavior are understood and the change removes meaningful burden or friction.
• Narrow the customer, input, or promise when variation prevents a coherent operation.
• Offer a bounded service when customers pay for expert judgment that does not need to become software.
• Stop when customers do not use or repeat the result, the work cannot be delivered responsibly, or founder rescue creates most of the apparent value.

The plan is ready for another run when every step has an owner, accepted input, observable output, quality check, failure boundary, and evidence record. The workflow is ready for a Beta Launch Plan only when the product can carry the stated part of the promise without private founder heroics. Manual work may remain around that boundary. What matters is that the founder and customer can both see where the product ends, where judgment begins, and what happens when either one fails.