The role-by-role AI diagnostic: a 4-step method

Ask ten consultants to estimate the automation potential of a finance department and you’ll get ten different numbers, all defensible out loud and none verifiable on paper. The problem isn’t the consultants’ skill — it’s that expert judgment, however well-intentioned, isn’t checked against any structured data. A role-by-role diagnostic replaces judgment with a reproducible four-step method, applied to your own data rather than a market average. Here’s how it works, step by step, and why each one conditions the next.

Why a method, not an estimate

An estimate, however expert, usually stops at the role level: “the accounts-payable clerk role is 60% automatable.” That sentence tells you nothing actionable, because a role isn’t a homogeneous unit. It bundles tasks of very different natures — data entry, verification, chasing payments, arbitrating disputes — whose automation potential can vary tenfold. A structured method systematically drops to the task level, because that’s the only level where a score actually means something precise: how many hours, on which activity, on what timeline.

It’s also the only level that allows honest consolidation. You can’t meaningfully add up qualitative, role-level estimates made by different people across an organization. You can add up task scores measured with the same grid, across the whole company.

The method in four steps

The principle is simple to state, demanding to execute correctly:

1. Decomposition — each role is broken down into elementary tasks based on existing job descriptions and real activity volumes (files processed, calls handled, entries posted). This step alone removes a lot of the fog: it forces you to document what teams actually do, not what the job title implies.
2. Scoring — each task is checked against a reference library of already pre-scored roles, to estimate its current automation potential given the state of available models. The score isn’t invented for the occasion — it rests on a shared reference frame built from comparable tasks already analyzed elsewhere.
3. Consolidation — task scores are aggregated up to the role, then from role to division, to surface real organization-wide priorities rather than isolated cases that look impressive but are marginal.
4. Quantification — the freeable time identified is converted into full-time equivalents, cost, or redeployable capacity, based on the organization’s own volumes and salaries, not a generic ratio.

The reference library: what makes the scoring defensible

The most fragile step in any estimation method is the scoring itself: on what basis do you claim a task is 70% automatable rather than 40%? Without a reference frame, that answer rests on the intuition of whoever is scoring it — however experienced, that’s a judgment call, not a measurement.

A reference library built from several hundred already-analyzed roles — close to 923 in the reference set used for these diagnostics — changes the nature of the exercise. A newly encountered task isn’t scored in a vacuum: it’s matched against comparable tasks already evaluated elsewhere, with their own observed outcomes. The score becomes traceable to a specific comparison, not to an opinion.

A score that can’t be traced back to a specific task and a comparison data point isn’t a score. It’s an opinion with a percentage sign attached.

Three depths, three uses

The method isn’t always deployed at the same granularity, because not every decision requires the same level of detail:

1. N1 — the strategic view. A map of the whole organization, division by division, in about three weeks. It’s used to prioritize: which divisions to tackle first, and roughly what scale of gains to expect.
2. N2 — operational deep-dive. Once priorities are identified, a finer diagnostic, division by division, down to the specific tasks and teams involved.
3. N3 — implementation support. Turning the diagnostic into a concrete, role-by-role action plan with the operational teams themselves.

Starting straight at N2 on a division assumed to be a priority, without a prior N1, is a bet on intuition — exactly what the method is meant to avoid.

Why push mode simplifies everything except the rigor

In practice, the diagnostic runs in push mode: the organization sends an Excel export of its roles, volumes and salaries, without ever granting access to its internal systems (HRIS, ERP, or otherwise). That removes most of the usual bottlenecks — IT security reviews, access provisioning, technical integration delays — that typically push back enterprise data projects by several weeks.

This operating mode lightens the logistics, but it doesn’t excuse the quality of the data handed over. An incomplete export or rough, self-reported volumes produce a biased diagnostic no matter how rigorous the method downstream. The speed of push mode should never become an excuse to rush the client-side data preparation.

What invalidates a diagnostic before it even starts

Certain upstream mistakes make the method inoperative regardless of its intrinsic quality:

• Outdated job descriptions — decomposing a role from a description that no longer reflects real activity produces a diagnostic of a job that no longer exists.
• Unverified, self-reported volumes — replacing measured activity data with managerial impressions distorts every downstream score.
• Scoring without a reference frame — eyeballing each task, division by division, with no shared comparison library, reintroduces exactly the bias the method was supposed to remove.
• Consolidation that stops at the role level — without aggregation up to the division, there’s no objective way to prioritize between two departments competing for the same transformation resources.
• A diagnostic frozen in time — a score valid in January isn’t necessarily valid a year later, as models improve and the organization itself changes.

The method doesn’t replace leadership’s judgment. It finally gives that judgment something solid to stand on — which is precisely what was missing until now.