Anyone wanting to introduce AI in their organization typically encounters two different approaches: generic lists of possible use cases - or large-scale strategy processes that take months and deliver surprisingly little concrete outcome. Both help small and medium-sized enterprises only in limited ways.

You can't just copy the best AI strategy from the competition on the cheap. Because by then, they've already won.

— Steven Broschart

The following procedure starts at a different point. It doesn't begin with an industry list, but with a concrete pain point in your organization. It translates the risk questions from my previous essay into a practical approach - who bears the error, is it visible, is it reversible - supplements them with a fourth dimension (frequency and distribution) and turns them into a sequential process.

The result is not a strategy document, but a concrete decision:

We're automating this one task now - with clear boundaries and comprehensible risk.

A preliminary note: This text is the third part of a small series. In a first article, I described the five application areas of AI in organizations - automation, insight generation, decision support, product innovation, and creative generation. In the second article, the risk question was central: Not the task itself determines suitability for AI, but the structure of the potential error.

This text combines both into a practical procedure - primarily for the automation field, because that's where most organizations actually start their AI transformation. The other areas follow partly their own logic and would require different procedures. However, some fundamental principles can be transferred.

The basic attitude: bottleneck before strategy

Before talking about AI, it's worth clarifying your basic approach.

Most AI implementation programs work top-down: First a strategy is formulated ('We want to become AI-driven'), then action areas are derived from it, and then pilot projects. The problem with this approach: The most abstract levels are decided first - and that's exactly where the most expensive wrong assumptions often emerge later.

The following procedure works the opposite way. It begins with a concrete pain point in your organization: something that isn't working now, that people in the organization can name, and that has measurable consequences.

From this one point, a single, carefully reviewed AI application is derived. Only once this is working and organizationally accepted does the next step follow.

This is slower than the strategy workshop promises. But it's the only speed at which organizations actually learn.

Step 1: Identify the bottleneck

The first question is not:

"Where could AI help?"

but:

"Where does it hurt?"

The difference is considerable. The first question produces hypothetical possibilities. The second delivers real problems.

A good bottleneck has three properties:

  • Perceptibility Employees report it unprompted, managers know about it. It comes up in conversations, complaints, or overtime.

  • Measurability Cycle times, error rates, complaints, or delays can be at least roughly quantified.

  • Organizational isolability The bottleneck belongs to a concrete process or clearly identifiable department - not a diffuse overall problem.

When identifying it, it's worth explicitly not just asking managers. Employees' pain points are often more precisely describable than management's strategic concerns - and that's exactly where real value can be measured later.

A short workshop is often sufficient:

  • Which tasks create frustration?
  • Where do delays occur?
  • Which activities seem repetitive or error-prone?
  • What would actually help in daily work?

At the end of this step, there is exactly one bottleneck. Not three. Not five. One. The temptation to tackle multiple problem areas simultaneously is great - and almost always wrong.

Step 2: Break the bottleneck into subtasks

An identified bottleneck is almost never a single task.

"Our inside sales team is overloaded" is not an AI use case, it's a diagnosis.

In the second step, this diagnosis is broken down. The decomposition follows the actual workflow:

  • What specifically happens from beginning to end?
  • Which activities alternate?
  • Which take particularly long?
  • Who performs them?
  • What decisions are made?

The result is usually a list of ten to fifteen subtasks. This is exactly where many AI initiatives fail. They identify a bottleneck, apply a generic AI solution to it - and overlook that the bottleneck consists of many different tasks, of which perhaps only two are really automatable. A one-size-fits-all solution doesn't address that.

The decomposition, by contrast, reveals:

  • where time is actually lost,
  • which tasks are structurally similar,
  • and where the actual leverage point sits.

An interesting side effect often becomes visible: Even within what seems like a clear automation case, subtasks emerge from completely different AI application areas.

Example:

  • Classifying a request is analysis.
  • Creating a draft offer is generation.
  • Prioritizing a follow-up contact is decision support.

These differences are not academic. They change the risk structure of each task - and thus its assessment as well. At the end of this step is a list of actual work steps as concrete as possible, not theoretical functions.

Step 3: Test each subtask against the four dimensions

Now each subtask is evaluated individually. The first three dimensions come from the previous essay. The fourth supplements them with a question that often becomes decisive in practice: Not just whether errors occur, but how they distribute.

First dimension - Who bears responsibility for errors?

If an error stays internal, the risk is usually limited. The AI creates a suggestion, a person checks it before passing it on:

  • summaries,
  • research support,
  • first drafts,
  • internal pre-classifications.

Here the error stays in-house. Different for tasks with direct external impact:

  • automatic customer responses,
  • price decisions,
  • legally relevant assessments,
  • automated approvals.

There an internal error becomes an external risk.

Second dimension - Is the error visible?

This is the subtlest and often most dangerous dimension. A wrong text becomes visible when read. A miscategorized dataset often does not.

When an AI:

  • prioritizes requests,
  • filters documents,
  • sorts leads,
  • or categorizes cases,

then you only see what was processed - not what was overlooked.

What the AI shows is visible. What it passes by remains invisible.

Particularly classification and filtering tasks therefore have special fragility: their errors often disappear silently in the process.

Third dimension - Is the error reversible?

Can an error be corrected before real consequences occur? A poor draft:

  • can be discarded.

An automatically sent message:

  • cannot.

Reversibility is therefore a central safety net. The shorter the time between AI output and real effect, the riskier the task becomes. This is exactly why real-time applications are often problematic:

  • live chatbots,
  • automatic responses,
  • spontaneous approvals,
  • real-time decisions.

They often combine:

  • external impact,
  • low visibility,
  • and low reversibility.

Fourth dimension - How do errors distribute?

A 1% error rate is not automatically harmless. What matters: do errors randomly hit different cases - or always the same type of problem? If a system:

  • reliably overlooks all edge cases,
  • misprioriti zes certain customer groups,
  • or systematically fails with certain data constellations,

then it's no longer a statistical outlier problem, but a structural blind spot. This question is almost never systematically addressed in strategy workshops.

The actual evaluation logic

For each subtask, a rough estimate is made:

  • favorable,
  • problematic,
  • or blocking.

Here it's explicitly not about point systems or scoring models. What matters is the combination of risks. A task with one problematic value can often be manageable. A task with two or more problematic dimensions usually tips into risk. Particularly critical is the combination:

external impact + low visibility.

Because here errors can:

  • have external effects,
  • accumulate simultaneously,
  • and remain undiscovered for a long time.

Step 4: Choose the safest entry point

Most AI strategies recommend:

Begin with the biggest lever.

This procedure recommends something different:

Begin with the safest profile.

The reason is simple: Organizations first need to learn how the technology behaves in their own context. An organization that starts with a high-risk task usually only learns that something went wrong. An organization that starts with a well-controlled task, by contrast, learns:

  • where models make errors,
  • how employees react,
  • which control mechanisms work,
  • and what organizational questions emerge.

Therefore, good entry tasks are usually:

  • internal,
  • visible,
  • reversible,
  • and asynchronous.

Typical examples:

  • research preparation,
  • text drafts,
  • summaries,
  • pre-classifications with human review.

They rarely seem spectacular. But they allow learning without collateral damage. Only once these initial applications work stably and are organizationally accepted should the next level follow.

The procedure with the example of an inside sales team

An example makes the procedure more concrete.

The bottleneck

The inside sales team of a mid-sized machinery manufacturer is overloaded.

  • Quotes take too long,
  • customers complain,
  • employees work overtime.

The problem is:

  • perceptible,
  • measurable,
  • and organizationally clearly assignable.

The decomposition

What specifically happens with a request?

  • Read email
  • Classify request
  • Check customer history
  • Research technical details
  • Compare previous quotes
  • Create quote draft
  • Get technical review
  • Correct
  • Send
  • Document in CRM
  • Plan follow-up

Already here it becomes clear: The seemingly simple automation case contains:

  • analysis,
  • generation,
  • and decision support.

The evaluation

Request classification

  • internal
  • low visibility
  • high reversibility
  • problematic error distribution

Assessment: suitable with spot checks.

Quote draft

  • internal
  • high visibility
  • high reversibility
  • non-critical error distribution

Assessment: ideal entry point.

Automatic sending

  • external impact
  • low visibility
  • low reversibility
  • critical error consequences

Assessment: currently unsuitable.

The example shows: The "big bang" - fully automated processing - would be precisely the riskiest solution.

The procedure instead forces sequencing: first controllable tasks, then gradual expansion.

Less spectacular. But significantly more robust.

What this procedure does not accomplish

This procedure does not replace:

  • technical review,
  • data protection assessment,
  • legal analysis,
  • or organizational responsibility.

It also provides no guarantee that an AI project will succeed.

What it does accomplish is something different:

It gives an organization a meaningful first step.

And it forces you to make the actual risk structure of AI deployment explicit:

  • Who bears the error?
  • Is it visible?
  • Is it reversible?
  • And how does it distribute?

Whoever takes this approach seriously will often find that large AI initiatives break down into several smaller tasks, each of which remains verifiable. This is not a step backward. It's exactly the speed at which organizations actually become productive with new technologies - instead of just appearing visibly modern.