What should you automate first?

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.

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.