The question I want to ask about automation is simple: how much work will still be left for a person? Connecting file intake to a notification can be quick. Someone still needs to check whether the right file arrived and respond when the flow stops.

I would first write down the current process: what comes in, where it goes and where someone makes a decision. That helps identify a sensible starting point.

An asset intake example

Imagine a video workflow: we receive a file, record its project and version, check the information and pass it to the owner. Someone then approves it or sends it back for changes.

I would start with registration and a receipt notification. I would leave approval with a person until we have a clear understanding of that decision.

If one file has three project names in three places, we first need to agree on an identifier. Otherwise, we simply move the ambiguity into the automation.

The calculation I would want to see

Suppose 40 assets arrive each month. Registering and handing over each one takes 6 minutes: 240 minutes, or 4 hours.

After automation, we still spend 2 minutes checking each asset, totalling 80 minutes. Allow another hour per month for maintenance and exceptions. Setup took 8 hours. These are fictional figures we can use to work through the calculation.

Net monthly time saving =
manual work − review − maintenance

4 h − 1.33 h − 1 h ≈ 1.67 h per month

Time to recover the setup effort:
8 h / 1.67 h ≈ 4.8 months

I find that more useful than saying the automation saves four hours. Review and maintenance still remain.

This only measures time. A financial calculation also needs licences, infrastructure and people's different hourly costs. If review and maintenance use up all the saving, setup time is not recovered in this model. There might be another benefit, such as fewer errors, but I would want to check that too.

What happens on a bad day?

Before putting the flow into everyday use, I would work through a few questions:

  • What happens if the file arrives twice?
  • How do we spot a missing project identifier?
  • Who gets a message if the destination system is unavailable?
  • Can someone finish the job manually?
  • Where can we see events and status history?
  • Who checks the flow after changes to connected systems?

Receiving the same file again should not create another task if the event has already been processed. And an operation that failed should not look complete.

I would test those situations. Later, I would compare the hours actually spent with the original calculation. That shows whether the idea helped and what still needs work.

If AI is part of the flow, its output review needs counting too. A single-task trial can help with that. For me, successful automation makes everyday work easier to follow and requires less attention overall.

A concrete example from ApprovalDock

My work on ApprovalDock includes the media approval flow. The product keeps file versions and decision history together, sends review requests and supports reminders while a human response is still needed. The flow is shown on the ApprovalDock website.

The reminder is the part that can be automated. A person still makes the decision about the work. A useful flow has to know who has not responded, whether a new version has replaced the file and whether the request is still current. A simple rule to send a message after three days does not resolve that context on its own.

This is a real product example. The hours in the earlier calculation are a teaching example, not measured results from ApprovalDock customers.

Try it in your own work

For a team choosing its first AI improvement, I suggest starting with a review of everyday work and small trials. More about the approach: AI review and workshop for your team.