What should you automate first?

Choose a repeated task, separate hands-on work from waiting and test one change. Includes a private workflow planner and an illustrative approval example.

By dglUpdated

Start with a repeated task you can describe and observe. Remove an unnecessary step before building around it, then test one change with the person who does the work.

Follow one real task from start to finish

Choose a recent request, appointment, approval or status update. Write down what started it, which information was needed, who touched it and what counted as finished. Include the spreadsheet, inbox and informal message that sit between the official steps.

Keep two kinds of time separate: hands-on work and waiting. Copying details for six minutes is different from waiting three days for a decision. A faster copy step does not remove that wait.

Starts when: the event that creates the task.
Needs: the information and access required.
Passes through: the people and tools involved.
Finished means: an observable result.
Gets stuck when: an exception or missing decision.

Ask the person doing the work to check this description against a recent example. BDC's process-mapping guide explains how a map makes steps and responsibilities visible. Include the informal handoffs as well as the named systems. The worksheet here is a planning exercise, not a diagnosis of your business.

Try removing a step before automating it

Mark each step as needed, duplicated or unclear. A second spreadsheet may exist because nobody knows who owns the first. Repeated reminders may be a missing decision deadline. An integration cannot settle either question on its own.

BDC's guidance recommends improving the underlying process alongside technology. For your first change, compare three possibilities: stop a step, change the way people handle it, or use software to support it.

The spreadsheet may stay. The copying and pasting is negotiable.

An approval queue with a named decision

Illustrative example: a private office coordinates material selections with a design practice. An assistant gathers comments, a principal approves the selection and the practice updates the project record. Comments arrive in different email threads, so the assistant repeatedly asks which version is current.

A proposed first change, to test with fictional material
Observed problemProposed changeWhat still needs a person
Comments refer to different versions.Give each selection a title, revision and current status in one agreed record.Someone confirms which version is ready for review.
Nobody can tell whether comments mean approval.Keep “comments received” separate from “approved,” with an identified approver.The authorised person makes the decision.
A reminder goes to everyone in the thread.Route the next-action reminder to the responsible person.Someone handles absence, disagreement or a changed deadline.

The first version might use an existing project tool. Before building a portal, test whether that tool can show the current revision, named decision and next action clearly. “Approved” should describe a recorded decision about a particular version, not a guess made from a reply.

Test the ordinary case and the awkward one

Use made-up records to try a missing detail, a duplicate request, a changed decision and an unavailable connection. Decide what should stop, who should be notified and how a person can continue. Do not silently send uncertain data into the next system.

Write the acceptance check before the change. For this example: a colleague can find the current version, identify who must act and distinguish comments from approval. Record hands-on time before and after using comparable tasks, including correction and checking time. Keep waiting time separate.

Time currently spent is a starting measurement. It is not time you will automatically recover. A new tool also takes setup, training and upkeep; a rare task may still matter because a mistake is disruptive. Use the estimate with that context.

Find the first thing to fix

Choose one task and estimate the time you currently spend on it. This makes a starting brief, not an automation plan or a promise of time saved.

No names, client details or account access needed. This tool runs in this page, sends nothing to dgl and does not save a copy for you.

All three fields are required. Use one person's task or a team total consistently. Count hands-on minutes, not time spent waiting for a reply.

Use a whole number. Choose a typical week or, for occasional work, a week when it happens. Note which kind of week in your brief.

An estimate is enough to start. Check it against a few real examples later.