Which business processes are worth automating?

How do you define a useful process boundary?

“Automate sales” does not yet describe an implementable project. A more specific task is: “Match new enquiries to an existing CRM contact and flag missing details for review.” This makes it possible to identify the input, data and desired result.

Describe the start and end in one sentence each. Record every manual handoff in between. If people understand the result differently, resolve that before development.

Which workflows are good candidates?

• Recurring enquiries with known required information.
• Regular data transfers between two applications.
• Known document types with information that can be checked.
• Approvals with defined responsibilities and deadlines.

Check whether automated handling actually replaces work. A process can be very frequent and still take little effort. Conversely, a few complicated cases can account for almost all handling time.

Complete the Process Score

Assess a specific workflow, ideally together with the person handling it. The score compares eight prerequisites. Unknown answers should be treated as open questions, not favourable assumptions.

What does the score tell you?

Each dimension receives 0 to 5 points. All eight values carry equal weight. Few exceptions and easily corrected errors receive high scores. The total can therefore help identify preparation needs; it does not calculate costs or expected savings.

The scale is my practical assessment model. It has not been scientifically validated. A one-point difference is not a precise forecast; the open questions behind the values matter more.

How do you use the result?

A document process might score 29 out of 40, but only two points for data quality. This is a calculation example, not a client result. The first question would still be: which details are missing, and how are they detected?

An intake check may then be more useful than immediately transferring data into the CRM. The score thus indicates where work should begin rather than simply returning a positive or negative verdict.

When should you take a different approach first?

• The task is a one-off or will soon be discontinued.
• Nobody can make an authoritative decision on the rules.
• Data is regularly recorded incorrectly or incompletely.
• The required software cannot be accessed through an authorised method.
• Errors would have serious consequences without an effective review being possible.

Here, a better input form, fewer variations or clear responsibilities may do more. This preparation is part of a sensible review and no reason to rush into using AI instead.

How do you choose between several processes?

Compare realistic time savings, preparation effort and risks. A smaller workflow with access already clarified may be a better start than a large project with many dependencies.

Define a verifiable measure, such as manual minutes per enquiry or time until a draft is ready. Include difficult cases and rework too. A single successful test does not yet demonstrate consistent value.

Which details help with the initial review?

• Trigger and desired result.
• Applications involved and known access methods.
• Approximate frequency and manual effort.
• A typical case and a known exception, without sensitive data.

This lets me assess open questions and define a possible first project. Costs and timing follow that clarification.