A PRACTICAL GUIDE FOR INDEPENDENT CREATIVES

Evaluating an automation after launch

A launch is a starting point for review, not proof that an automation has helped. Compare the work with the starting point you agreed, look at what actually happened, and decide what needs attention next.

This guide helps you assess one completed admin automation. It does not promise a particular result or a set amount of time saved.

Begin with the work as it was before launch.

Find the starting point you agreed with the person who set up the automation. It should say which task is included, what a completed task means, which steps stay with you, and what you will compare. For a creative business, that might be answering routine commission questions, confirming a studio visit, or sending an order update.

Use the same kind of work and a comparable time period on both sides. A quiet month and a busy market season are not an even comparison. If the original notes or records are missing, say that the starting point is incomplete; do not present a memory-based estimate as a measured result.

Use the same questions on each side.

Keep the agreed measure and count the full task, including review and corrections. Record where each number or note came from.

How much work came in?

Before launch

Count the inquiries, orders, bookings, or other items handled in the period.

After launch

Count the same kind of items over a comparable period.

How much time did the whole task take?

Before launch

Include finding details, doing the task, and checking the result.

After launch

Include monitoring, review, corrections, and any work that still happens by hand.

What needed a person?

Before launch

Note the usual manual steps and the cases that needed judgment.

After launch

Count and describe reviews, edits, exceptions, and work returned to a person.

Was the result right and useful?

Before launch

Write down the quality checks and the result you agreed to expect.

After launch

Use the same checks. Note mistakes, delays, duplicate actions, or unclear handoffs.

Keep observations separate from estimates.

A clear review tells the reader what was recorded, what was calculated, and what is only an example. Do not turn an estimate into a claim about what happened.

OBSERVED

What your records show

Use a dated log, order record, or notes from checking the work. Sample wording: “My record for [date range] shows [number] order updates; I corrected [number] before they went out.” Replace the brackets only with counts you actually checked in your own records.

ESTIMATE

What you calculated

Show the inputs and method. If you estimate time from a sample, label it as an estimate, include time spent checking and correcting, and explain what the sample does not cover.

HYPOTHETICAL EXAMPLE · NOT OBSERVED

How an estimate could be worked out

Sample figures only: suppose 8 routine questions took about 6 minutes each before launch (48 minutes), and checking the prepared replies took about 2 minutes each afterward (16 minutes). The arithmetic gives an estimated difference of 32 minutes for those 8 questions. These figures are made up to explain the calculation. They are not observed client results, do not predict the result for a real task, and are not a typical outcome. Setup, unusual questions, corrections, and other work would also need to be counted.

There is no guaranteed result or typical amount of time saved. The result depends on your task, the amount and type of work, and the review it still needs.

Record the cases that did not follow the usual path.

Exceptions show where a person still needs to step in. Note what happened, how often, what you did, and whether the agreed safe fallback worked.

  • Information is missing

    Record what was missing, whether the automation paused, and who completed the task.

  • A request is unusual

    Note when a custom commission, order change, or sensitive question needed your judgment.

  • A step is late or repeated

    Record the delay or duplicate, the effect it had, and the safe action you took.

  • An account or tool changes

    Note changed access, settings, or a service interruption and who was told.

If an error could send the wrong price, date, payment request, or client information, follow the documented pause or manual fallback. Do not retry blindly or change access rules just to make a run continue.

Decide who will keep it dependable.

An automation may need attention when the way you work, an account, or a connected tool changes. Put the ownership and next review in writing.

  1. 01

    Name a person responsible for review.

    They should know where to check activity and who to contact if it stops.

  2. 02

    Set a review rhythm that fits the risk and workload.

    Choose when to check it based on how often it runs and what a mistake could affect. There is no single schedule that suits every studio or task.

  3. 03

    Recheck it after meaningful changes.

    Check the automation again if you change its steps, account access, order process, or a connected app or service. Keep passwords and secret keys out of shared notes.

  4. 04

    Keep a short record of fixes and decisions.

    Note the date, what changed, who checked it, and what still needs follow-up. Keep only the client information you need for that record.

Write down the evidence, exceptions, and next step.

Keep the agreed starting point, the period you reviewed, the records you checked, what you observed, any estimates and their assumptions, the exceptions, and who owns the next maintenance check. If you cannot make a fair comparison, write down what is missing and collect better records before reaching a stronger conclusion.