Adoption came before the decision
A team took seats on its own budget, the results convinced everyone, and the rollout spread without anyone defining what was expected or how it would be measured.
Platform · Claude
Claude is already running in your teams. What actually comes out of it?
Claude rarely arrives through a procurement plan. It arrives through one engineering team that adopts it, then through projects and skills each person builds alone. Six months later the technical leadership holds premium seats, an invoice that follows the models being called and no view of what any of it produces downstream.
Book a 30-minute discovery callIn short
On a Claude estate, Anthropic's console shows activity and cost per person, not what the seats and agents produce downstream. An audit of real usage combines those logs with interviews to tell you which seats to resize, which uses to equip and what to cut.
The scope of this page
This page covers the use of Claude inside an enterprise, first and foremost Claude Code and the shared assets, projects and skills. It does not compare models against each other and names no winner: it provides the grid and the data that let you decide.
Markers
- 40+AI diagnostics delivered in a year
- 41,200users measured
- 85%real activation measured at Inskip (33 users across 39 seats)
- 12 to 25xwhat the three heaviest users return against their seat, at Inskip
NoteFirm markers and engagement findings. The Inskip figures are publishable under the agreement of 27 August 2026; they were measured on one month of logs, the export's retention being thirty days. None is a guaranteed outcome.
Why Claude ends up on the table
In short
Claude almost never raises an adoption problem: it settles in through use, often very fast. It raises a steering problem, because adoption comes before any framing. Five situations recur.
Two seat tiers, two unrelated uses
The premium seat and the standard seat do not cost the same and do not open the same usage allowance. Assigning them by job title rather than by observed use is paid for every month.
Ceilings hit on one side, dead seats on the other
The most productive profiles run into their limits while other seats leave no trace at all. Until both populations are identified, you buy instead of reallocating.
Shared assets do not really exist
Projects, skills and instructions get built locally and stay private. The same need ends up handled in several competing versions, with nobody seeing it.
An invoice that follows models, not headcount
When usage is billed beyond the seat, spend depends on the models called and the tasks launched. It stops being predictable from the number of people equipped.
What Claude does inside an organisation
In short
On the Claude estates we open, five uses recur: Claude Code inside engineering teams, shared projects, shared skills, connectors into the information system, and uses outside engineering. For each one: what it is, what measurement reveals there, and the decision it enables.
| Use | What it is | What measurement reveals | The decision it enables |
|---|---|---|---|
| Claude Code inside engineering teams | The coding agent that reads the codebase, plans and executes in the terminal: migrations, tests, pull request review, debt recovery. | The console already gives accepted lines, the edit acceptance rate and pull requests merged with or without assistance. What it does not give is what those merges become: a merge is not a release, and the gap between the two is what tells you the real return. | Resize premium seats against observed use, and target support where the acceptance rate drops. |
| Projects and shared context | Spaces that carry a context, reference documents and durable instructions for a team or a topic. | How many projects exist, which ones are actually alive, and above all how many carry the same context in several copies. That is the most common symptom of a fast rollout. | Merge the duplicates, designate the reference projects, and turn context into a team asset rather than a personal folder. |
| Shared skills and instructions | Reusable capabilities a team writes once: an assessment grid, a report format, a briefing template. | Which ones are published across the organisation and which stay private, the redundant ones, the ones that contradict each other and the ones nobody calls. A published asset reaches far more people than its personal version. | Publish what is being recreated everywhere, retire what no longer serves, and settle who holds the shared library. |
| Connectors into the information system | The links that bring Claude to repositories, databases and document spaces, through the MCP protocol or through native connectors. | Which ones are actually called, by whom, and which questions go unanswered for lack of a connected source. That is a diagnosis of your own estate as much as of the tool. | Connect the right sources before widening the estate, and remove links that open access nobody uses. |
| Uses outside engineering | Writing, document analysis and case preparation across support and business functions. | A very uneven distribution: a handful of people carry most of the activity, and depth of use separates those who reach a finished deliverable from those who stop at the first draft. | Target training on depth rather than on getting started, and resize seats at renewal. |
The five criteria that settle it
In short
We publish no ranking between platforms. We publish the grid a leadership team uses to decide for itself, and what to look at to fill it in for Claude specifically. The five criteria hold across all the platforms we measure, the middle column changes every time.
| Criterion | What to look at | What it tells you |
|---|---|---|
| Fit with the working environment | The terminal and the repository for technical teams, connectors and projects for everyone else. Does the use force people out of the tool where the work happens | On Claude the fit plays out on the engineering side first, which is where adoption settles on its own |
| Quality on the intended task | The edit acceptance rate, and what becomes of pull requests merged with assistance | A market average says nothing about your codebase |
| Governance and administration | How seats map to identity groups, how authorised connectors are managed, and who holds the shared skills library | This is what conditions any rollout beyond the pioneering teams |
| Cost per seat against real use | The split between standard and premium seats, ceilings hit, spend concentration and the models being called | The only criterion that turns spend into return, and the most volatile one on Claude |
| Sovereignty and hosting | Where processing happens, contractual commitments, conversation retention policy | Often an entry constraint, rarely a differentiator on its own |
What we put in place once the measurement is done
In short
Once the measurement is done, three tooling moves follow, from the least costly to the most committing: publish the assets, connect AI where the work happens, share agents across teams. Measuring changes nothing on its own, and you do not fix a usage by asking teams to do better.
Publish the assets
Projects, skills and instructions get built locally and stay private, so every team rebuilds the same ones. Publishing them across the organisation costs nothing and makes practice converge. It is the move that pays back fastest on a Claude estate.
Connect AI where the work happens
Connectors and the MCP protocol bring Claude to the repository, the database and the document space. A use that forces people to paste the context every time never settles in for good.
Share agents across teams
On the needs measurement has shown to recur from one team to the next: one shared agent replaces as many private automations. It is the most committing lever, and the only one that gets decided on data.
What really drives the cost of a Claude estate
In short
The real cost of a Claude estate comes down to six mechanics: two seat tiers, usage billable beyond the seat, ceilings that flip the billing mode, the model called, spend concentration and the hidden cost of rework. We publish no amounts, neither ours nor any vendor's: a price list goes stale and says nothing about your situation; the mechanics decide.
| Mechanic | What it covers | Effect on real cost |
|---|---|---|
| Two seat tiers, not one | The standard seat and the premium seat do not open the same usage allowance. Assigning tiers by job title rather than by observed use is the first source of waste. | A bad mix of the two tiers costs more than overstaffing |
| Usage can be billed beyond the seat | On enterprise plans the seat comes with consumption billed at programming interface rates. Spend then follows the models called and the tasks launched, not the number of people equipped. | Spend stops being predictable from headcount |
| Ceilings flip the billing mode | When a usage limit is reached, consumption can switch to pay as you go. The switch shows up on the invoice before anyone anticipates it, unless someone watches the ceilings. | An overrun gets discovered after the fact |
| The model called changes the invoice | Not every model costs the same on a given task. A usage that systematically calls the most capable model on tasks that do not need it inflates spend with no measurable gain. | Two teams at the same volume with unrelated invoices |
| Spend concentrates on a few people | The console shows this itself. That concentration is not a problem in itself, it becomes one when the heaviest users run into their ceilings while other seats lie dormant. | An arbitrage that is often cost neutral |
| The hidden cost of rework | Time spent reworking an output, relaunching a badly framed task or undoing what an agent produced appears on no invoice. On some uses it exceeds the time returned. | Can exceed the time returned |
NoteNo figure is given before the analysis. The real cost of your estate is computed on your own logs and presented in a meeting. Targeted and measured at your side: a 30 to 50% reduction in the cost of the usages in scope, never the whole invoice. That is an engagement objective, never a result announced in advance.
The shape a Claude estate takes
What your console shows, and what it does not
In short
Let us say it up front: Claude's console is one of the most complete on the market. It even carries cost per person, which few vendors do. All the more reason to state precisely what it covers before stating what escapes it. Everything below can be verified in Anthropic's documentation.
What the data shows
- Activity and seat utilisation: Weekly and daily active users, seat utilisation, pending invitations, most used connectors.
- Usage and cost, by group and by person: Rare and valuable: spend is placed next to what was produced, artifacts created, files edited, skills and connectors called.
- The spend tab: Totals by month, quarter and year, breakdown by model, spend concentration and the largest contributors.
- Claude Code metrics: Lines of code accepted, edit acceptance rate, sessions, pull requests merged and lines committed, with and without assistance.
- Mapping to identity groups: Breakdowns follow the groups your IT department already manages, rather than a split invented for the occasion.
- A programming interface and a telemetry export: Programmatic access to the same metrics, and an OpenTelemetry export into your own observability chain.
What it does not show
- What happens after the output: A merged pull request is not a feature in service, an artifact created is not an artifact reused. What happens downstream cannot be read in the console.
- Competing assets: The console gives the skills called, not the same need written in several versions that contradict each other. No console exposes it.
- Time actually saved: The estimate displayed is produced by the vendor, with its own method. It orients a decision, it is not presented to a finance department as a measured result.
- Intent: Why a team stopped opening the tool is not in there. An interview gives that, never a log.
- What happens elsewhere: By construction the console covers the Anthropic perimeter. It allows no comparison of the same use case from one platform to another.
- History, if telemetry was never enabled: The OpenTelemetry export is opt in. An estate that never switched it on has no history to read back, and measurement starts the day it is turned on.
NoteNone of this is a product flaw: a vendor instruments its own perimeter, that is expected, and Anthropic does it better than most. What we add is the view across every tool, the reading of what happens after the output, and the interview that gives intent, built from the same exports you already administer.
How we measure a Claude estate
In short
Claude is never alone in an organisation. The measurement that counts is the one that places it back among the other tools in the estate, because it is the only one that lets you compare the same use case from one tool to the next.
The logs and exports you already produce
We start from what the platforms you administer produce: Claude, but also internal models, other assistants and custom agents. Nothing to install on workstations, no reinstrumentation. Export handover or read only access, the exact arrangement is settled in the framing meeting.
The view across every tool
A vendor console covers its vendor's perimeter, by construction. It does not see the people who switched elsewhere, nor the same need handled on two platforms. That consolidated view is what makes an arbitrage possible.
Interviews, for what logs cannot say
Logs give the facts: who uses what, how often, at what cost, with what error rate. They do not give intent. Interviews with the IT department and the business units are a mandatory step. Interviews and data, never one in place of the other.
A readout that holds up in front of finance
The document reads without reprocessing. Finance finds the full cost and the spend concentration, the technical teams the detail by seat tier and by model, HR the training need that follows from it.
The measurement loop
Three deliverables
The map
What teams actually do with Claude and with the rest of the estate: use cases detected, real adoption per unit, projects and skills created, published or left private.
The account
What each use case costs and what it returns: standard and premium seats set against observed use, ceilings hit, models called, consolidated full cost.
The course
What to industrialise first, which seat tiers to reallocate at renewal, who to train on what.
Usage, never people
We analyse usage, never people. Results are aggregated per team and per tool, and the exact processing status is validated with your data protection officer. Read only, no writes into your systems, no scanning of workstations, no reading of your code repositories. The report also carries its appendix of unsaid things: the perimeter actually covered, what we could not see, and the figures we refuse to put forward.
What we have already measured on Claude
In short
On Claude, we measured the estate of Inskip, a consulting and training firm. Idun Group does tooled consulting and resells no platform: we have to be able to conclude that the tool is not worth what it costs at your side.
Inskip
At Inskip, a consulting and training firm, the analysis of real Claude usage established 85% real activation: 33 active seats out of 39, including 8 false starts. With the 4 seats that left no trace at all, 12 seats out of 39 were to be reassigned or activated. At Inskip, the three heaviest users' consumption is worth, at API prices, 12 to 25 times the price of a premium seat.
The limitThe limit, written at the top and never in an appendix: the platform export had a rolling thirty-day retention while the rollout had been running for five months. One month out of five was measured.
What leadership teams ask us
What does Claude cost for an enterprise?
We publish no prices, neither ours nor any vendor's. And on Claude the headline price tells you less than elsewhere: spend depends on the mix of standard and premium seats, on the models called and on the ceilings hit. That mix is what gets measured.
What is the difference between a standard and a premium seat?
The two do not open the same usage allowance: the premium seat opens a much larger one. The most common mistake is to assign tiers by job title rather than by observed use.
Our console already gives cost per person, so what do you add?
It does indeed, and that is rare. It covers the Anthropic perimeter though, it does not say what becomes of a merged pull request, and it does not see skills written in several competing versions. That is where we come in.
How do we know our Claude Code seats are really working?
By placing the edit acceptance rate, the pull requests merged with assistance and what those merges become next side by side. A merge is not a release, and the gap between the two is what tells you the return.
Do you analyse our source code?
Not your repository: we read neither your repositories nor your files. We read Claude Code's usage logs; if your settings let prompt text into them, they can hold code excerpts, and we do not hide it. We measure usage, never the quality of your code.
Are you an Anthropic reseller?
No. Idun Group is an independent consulting firm and resells no platform. Our measurement tool, Idun Cockpit, can be kept after the engagement, on subscription: it measures the platforms and replaces none of them.
Does anything need to be installed on our workstations?
Nothing. We work from existing exports and logs, read only, with no reinstrumentation. Processing runs in France, at Scaleway in Paris, or inside your perimeter if your policy requires it.
Will our teams feel individually monitored?
No. It is a method rule: we measure usage aggregated by team and by tool, never a named employee's activity. We do not look for who uses the tool badly, but for where the tool is badly set up.
Do you know what your Claude seats produce downstream?
Thirty minutes to frame the perimeter, the platforms to read and the renewal date you have in mind. You leave with a straight verdict on whether the exercise is worth running at your side.
Book a 30-minute discovery callRead-only. We analyse usage, never people.
Supported by
