Start with the decision
A marketing system earns its place by helping someone do something useful. Before choosing software, describe the decision or output it should improve. A weekly report might help a channel owner choose the next experiment. A content workflow might help an editor approve a well-supported first draft. Those are different jobs, even if both use the same model.
Write a short outcome statement with the person who owns the work. Include the current constraint, who receives the output, and what changes when it works. Avoid making automation itself the success measure. A process can run without intervention and still produce something nobody uses.
- Who uses the output, and what do they decide?
- What is slow, unreliable or difficult today?
- What evidence would make the first release worth keeping?
Reconstruct the last real run
Ask the people closest to the work to walk through a recent example. Follow the brief, files, messages, spreadsheets and approvals in the order they actually happened. Record where information was missing, where someone corrected a number and where a decision moved into a private conversation.
The aim is a usable map, not an idealised process diagram. Separate the steps that happen every time from exceptions and judgment calls. A recurring delay may come from an undefined approval owner rather than the tool that sends the reminder. Fixing that ownership can be more valuable than adding another integration.
Give the workflow a contract
Define what starts the work, which inputs are required, what the output must contain and who is responsible for it. Be explicit about missing inputs. If an approved brief or a required data source is absent, the system should ask for it or stop at a known point.
The contract also names the human decisions. For a content workflow, software can gather approved sources, prepare a draft and check a required format. An editor still owns claims, tone and publication. For paid media, a proposed budget change remains a recommendation until an authorised person approves it.
- Trigger, owner and required inputs
- Output format and acceptance criteria
- Permissions and approval boundaries
- Known exceptions and escalation route
- Run record, recovery method and retention rules
Build the smallest useful loop
Choose a narrow path that reaches a real decision. An illustrative content loop could begin with one approved brief, assemble evidence from agreed sources, prepare one draft, run quality checks and send it to an editor. It does not need every channel, every document type or autonomous publishing to be useful.
Use fixed rules for tasks with fixed answers, such as required fields, date ranges and numerical calculations. Use AI where interpretation or generation adds value. Keep source material available beside the output so the reviewer can check why a recommendation was made. This makes the first release easier to assess and easier to change.
Test the awkward cases
A clean demonstration tells you little about a workflow that will meet incomplete briefs, expired permissions and contradictory source material. Build a small evaluation set from representative work, including the cases that have previously caused confusion. Agree which failures require a stop and which can be routed to review.
Check the output against the contract rather than asking whether it looks impressive. Is every material claim supported? Can a repeated run create duplicate tasks? Does a failed connection leave the last successful output distinguishable from fresh data? A failed check should produce a clear reason and an owner, not a confident substitute answer.
Make operating it part of delivery
Before release, someone should be able to start a run, understand its status, review an exception and stop it safely. Document the expected inputs, routine checks, account ownership and change process. Walk through a failed run with the people who will use the system, not only the happy path.
Observe what happens after the first release. Useful measures might include preparation time, correction rate, review effort and whether outputs inform a decision. Establish a baseline before treating a change as an improvement. Expand to another workflow only when the evidence and operating capacity support it.
Take the next useful step
Use this method to define a first release that people can assess, operate and improve. The appropriate tools, permissions, evaluation criteria and level of automation depend on the team and the work.
A useful first conversation starts with an outcome and a recent example. From there, we can identify what is already clear enough to build and what needs a paid diagnostic before implementation can be responsibly scoped.