Corporate Role Analyser

Two decisions in the day job kept coming back without an evidence base. The first is licence allocation: an organisation has a fixed number of Copilot seats and has to decide who gets them, and without knowing what people actually do all day the answer defaults to seniority, or to whoever asked first. The second is cross-functional opportunity. Finance, HR, procurement and patient services each run their own improvement work, and nobody can see that the task they're all trying to fix is the same one wearing different job titles.

Both need the same thing: a description of the work across every corporate team, at the level of individual tasks, that the people doing the work would recognise. The best thing I had was a dashboard of 745 tasks across 81 generic roles that an analyst had written from experience, which is an opinion with a nice interface.

What struck me was that the NHS already publishes the raw material. Every post is evaluated against a national job profile, and every vacancy goes on a public job site with a job description attached, written by the trust that needs the person. If I could turn those two public sources into a weighted task list for each role, the question of which work would benefit from AI could be answered from evidence rather than from a workshop.

Two public sources, kept physically separate in the database. The NHS Employers national job profiles give the band, the job evaluation score and the sixteen factor levels, which is the anchor nothing else can move. NHS Jobs adverts give the task layer: a harvester searches one keyword per suite and band, respects a two-second rate limit, strips contact details at ingest and stores every page and attachment raw.

The duties come out of the attached job descriptions rather than the advert summary, split into verb-led clauses, embedded locally and clustered so that two trusts describing the same task land in the same bucket. A task's weight is simply the share of a profile's adverts it appears in. Then Claude reads each core task with its suite, band, job statement and two real example clauses, and sorts it with a load type, an archetype, a blocker and a one-sentence reason. Everything ends up in SQLite, exported to a workbook and a static site: suite, profile, task, drill down.

Most of what I believed at the start turned out to be wrong in instructive ways. I started with O*NET, the US occupational taxonomy, as the task source and dropped it within days because it collapses the Agenda for Change band ladder that the whole analysis depends on. The first assessment pass used verb rules, where anything starting with "process" or "reconcile" was automated, and it was withdrawn after it called food service augmented.

The search itself needed learning. NHS Jobs matches any word of a query across the whole advert, so "finance assistant" returns every assistant in the band, and once that noise is stripped out the live market for one profile is around ten relevant adverts per snapshot, which turned out to be plenty to weight a profile against. And the advert summary box is exactly that, a summary, with a median of four clauses where the attached JD has twenty-eight; weights built on the summary would have understated every task. The biggest open question is the terms of use on jobs.nhs.uk, which allow personal extracts but not republication, so the harvest stays local and nothing quoting an advert goes public until that's settled.

The first window ran in October 2026: 862 adverts from 225 employers, 624 matched to a profile, 8,158 task clusters. Finance has been through a first pass of the assessment, and that pass is a starting point to test and challenge rather than a finding. The shares and the band patterns will move as the method is refined.

It isn't public and may never be in this form, and it is still very much a work in progress, building towards something a team could act on. I haven't settled how it will be used. Licence allocation makes sense as a first use, and looking across teams at where the same work shows up is another, but the simplest value may be giving a team something to test and challenge rather than starting a long, detailed exercise from a blank sheet. The next layer would be joining a trust's own establishment data so that task shares could turn into whole-time equivalents and cost.

The model was the easy part. Nearly all the effort went into the sources: parsing PDFs that defeat every library, learning how a job site's search behaves, deciding which section of an advert counts, and keeping every derived row traceable to the page it came from. That traceability is what makes the result defensible, and it's the thing I would have skipped if I'd been moving faster.

The other lesson is that the aim is something people can interact with to reach reliable data quickly, not a perfect answer produced in isolation. A department's disagreement is part of the design: every override is a new row that points at the row it replaces, never an edit, so the corpus gets better the more people argue with it, and a good-enough starting point that a team can challenge beats a polished one nobody has tested.

The first lesson is that there may well be public data sources you can combine into something useful, and use as an informed starting point. The adoption intelligence platform set out to collect its evidence from inside the business, through operational use, which is an uphill battle: it asks people to describe their work before anything useful comes back. Here the job profiles, the adverts and the job descriptions were already on the open web, and combining them gave a picture of corporate work that any later capture only has to refine.

The second is what the evidence is for. Licence allocation is the most immediate use: if you can see which roles carry the most automatable task weight, you can put the seats where the work will change instead of where the seniority sits, and you can say why. The cross-functional view matters more over time. Read the task clusters across suites rather than within them and the same work keeps appearing: chasing information, reconciling two systems, preparing papers for a meeting. Those are the opportunities worth a shared solution rather than three separate ones.

The assessment layer is a starting point for departments to overwrite, not a result, and it was designed that way on purpose. An organisation doesn't need an AI tool to tell it which tasks will change; it needs a shared, weighted description of the work that the people doing it recognise, so the conversation about where AI goes starts from the same list.