Week 1
Map it as it is
Including the informal steps and the workarounds, which is where the real process lives and where the waiting is.
AI-assisted workflows · Workflow automation · Sydney
Workflow automation
Most content does not take three weeks because anybody spent three weeks on it. It took three weeks because it sat in four inboxes, and that is an automation problem rather than a creative one.
Grab the snowball. Give it a spin, and watch it grow as you scroll. Just like the throughput.
4handoffs in a typical piece
1that genuinely needs a person
Waitingis most of the elapsed time
Not thinkingwe never automate the judgement
The short answer
What should content workflow automation actually do?
Content workflow automation is removing the mechanical friction between people: briefs that have to be typed twice, approvals that sit unnoticed, files that go missing, publishing steps done by hand. It targets waiting rather than working.
That distinction is the whole discipline. Measure a piece of content from brief to published and almost all the elapsed time is queue rather than effort. Automating the effort saves little; automating the queue changes the throughput of a team without anybody working faster.
We never automate the judgement, and we will say so when a request amounts to that. It sits inside our wider AI-assisted workflows service, and because our Snowball SEO platform automates the search heavy lifting other agencies bill by the hour, more of your budget goes into the work that needs a person.
The difference
Where does the time actually go?
Not where anybody guesses. Ask a team how long a piece takes and they will describe effort; measure it and you will find waiting.
Worth automating
- Briefs, so they are captured once in a form that is actually usable
- Handoffs and notifications, so nothing waits because nobody noticed
- Status, so nobody has to ask where something is
- Publishing mechanics: formats, sizes, scheduling, links
Never worth automating
- The decision about what to make, which is the job
- Approval of anything that carries risk
- The editing pass, which is where quality is added
- Anything where a person's accountability is the point
Where the assistance is in the making rather than the moving, that is our AI-assisted production work.
The cost
What drives the price of automating a workflow?
How many systems have to talk to each other and how messy the current process is. Automating a clear process is quick; automating an undocumented one means documenting it first.
Map and fix
Diagnosis
The current process mapped as it actually happens, with the waiting identified and the fixes ranked. Often enough on its own.
Automate the handoffs
Build
Briefs, notifications, status and publishing mechanics wired together so nothing waits for somebody to notice.
Full pipeline
End to end
Brief to published, with the human decision points kept deliberately and everything between them removed.
We quote after mapping the current process, which is frequently the first time it has been written down and is often the more valuable half.
What moves the number, in order
- How many systems are involved and whether they have usable interfaces
- How undocumented the current process is
- How many teams and approval layers are in it
- Whether the tools you own can do it or new ones are needed
- How much historical data has to be migrated
- Whether we maintain it or hand it over
Map before you automate
Automating a broken process produces a faster broken process, and the speed makes the problems harder to see rather than easier.
In most teams the map alone finds two or three steps that exist for no current reason: an approval for a person who left, a duplicate entry into a system nobody reads, a report generated for a meeting that stopped happening.
Removing those costs nothing and often produces more than the automation does. We will tell you when that is the case, and stop there if it is.
The scope
What you receive
A map, then the removal of what the map found.
The process map
How work actually flows today, including the informal steps, which is usually different from the documented version and more revealing.
Where the time goes
Measured rather than estimated, because every team estimates this wrongly and in the same direction.
The automated handoffs
Briefs, notifications, status and publishing wired so nothing waits for somebody to notice it.
Human decision points, kept
Deliberately preserved and named, so speed does not quietly remove accountability.
Documentation
How it works and how to change it, so you are not dependent on us to adjust your own process.
A handover
Ownership transferred, because an automated workflow only one supplier understands is a new dependency rather than an improvement.
The return
What does removing the waiting actually change?
Throughput, without anybody working harder, and a second effect that matters more: work becomes worth starting because it will not disappear for a fortnight.
The second effect is more valuable than the first
Faster throughput is the obvious benefit. The larger one is that small pieces of work become worth doing at all, because the overhead of getting something through the process no longer exceeds the value of the thing.
In most organisations there is a floor below which nobody bothers: a useful update, a small correction, a timely post. Lowering that floor changes what gets made rather than how fast.
That is the argument worth making internally, because throughput alone tends to be answered with a request for more output rather than better.
The process
How workflow automation runs
Three to six weeks, with the map first and always.
Week 1
Measure the waiting
Elapsed against effort on recent pieces, because estimates are wrong and consistently in the same direction.
Week 2
Remove before automating
The steps that exist for no current reason, which cost nothing to delete and frequently produce more than the automation.
Week 3
Design the flow
What routes where, what is chased automatically, and which decision points are deliberately human.
Weeks 4 to 5
Build and test
In the tools you already own where possible, tested on real work rather than on a sample.
Week 6
Hand over
Documented, with ownership transferred, so changing your own process does not require us.
The brief
What to ask before you automate anything
Automation projects fail by automating the wrong thing quickly, which is worse than automating nothing.
Will you map before you build?
Automating an undocumented process produces a faster version of whatever it currently is, including the parts nobody meant to keep.
What will stay human?
There should be a clear answer, and approval of anything carrying risk should be on it. Speed that removes accountability is not an improvement.
Can we change it ourselves?
If adjusting your own process requires the supplier, you have replaced a slow process with a dependency. Ask about documentation and handover before starting.
What can we simply delete?
A good map finds steps that exist for no current reason. A supplier who goes straight to building has skipped the cheapest available improvement.
We are happy to answer all four, and the map stands on its own if the honest answer turns out to be that you need less automation than you thought.
Start here
Ready to remove the waiting?
Tell us how a piece of content currently gets from idea to published. The free consult is a working session, not a sales call, and you leave with three things whether or not you book us.
- Your current process mapped as it actually happens, informal steps included
- Where the elapsed time is really going, which is rarely where anyone expects
- A fixed price, with the map available on its own
Good questions
Workflow automation FAQs
What should content workflow automation do?
Remove the mechanical friction between people: briefs typed twice, approvals sitting unnoticed, files going missing, publishing done by hand. It targets waiting rather than working, because waiting is where the elapsed time actually is.
What should never be automated?
The decision about what to make, approval of anything carrying risk, and the editing pass. Those are where judgement and accountability live, and speed that removes them is not an improvement.
How much does this cost?
We quote after mapping the current process. What moves it is how many systems are involved and whether they have usable interfaces, how undocumented the process is, how many approval layers exist, and whether we maintain it or hand it over.
Why map before automating?
Because automating a broken process produces a faster broken process, and the extra speed makes the problems harder to see. The map also routinely finds steps that exist for no current reason and can simply be deleted.
Where does the time really go?
Waiting in queues and inboxes, by a wide margin, then rework caused by unclear briefs, then the actual making. Every team estimates this the other way round, which is why improvement effort so often goes to the smallest slice.
Do we need new software?
Usually not. Most teams own tools that can do the majority of this and are not using the features. Buying new software before mapping the process is the most common way these projects go wrong.
What is the real benefit?
Throughput is the obvious one. The larger one is that small pieces of work become worth doing, because the overhead of getting something through the process no longer exceeds its value. That changes what gets made, not just how fast.
Who owns it afterwards?
You should, with documentation good enough to change it without us. An automated workflow that only one supplier understands is a dependency wearing the costume of an improvement.