Adoption & ROI

Adoption & ROI (under Monitor, and linked from the top of Executive) answers three questions for the period in the time picker:

1. Are people using the AI tools you pay for?
2. What do the seats nobody uses cost?
3. What time is AI estimated to save, and on what assumptions?

People are counted, not named. Neither the page nor its exports contain anyone’s name.

Where the figures come from

Figure	Source	Basis
People active, daily / weekly / monthly, days per person, depth, trend	AI tool responses the collector reports and time in AI web apps the browser extension reports	Count
Seats paid for, seats used, seat adoption	Subscriptions and their seat assignments, matched to usage the same way the spend report matches it	Count
Seat cost and unused seat cost	Priced by the function the cost ledger’s seat lines use, and checked against the ledger’s seats total	Billed
AI spend, spend per active person, spend by department	The cost ledger, the same total as Home, Costs, Finance and Executive	Billed, with any part Shield360 priced marked as an estimate
Use cases	AI responses (collector) and agents’ actions by type (activity provenance)	Count
Time saved, value of time saved	Counted work × the minutes you set per kind of work; value at the AI Code hourly rate	Estimate

Adoption

• People active: distinct people who reported activity with any AI app in the period, with the period before beside it.
• Daily (avg): people active each day, averaged over the period’s days. Weekly and Monthly: distinct people active in the 7 and 30 days to the period’s end. Daily ÷ monthly shows how much of a month’s population uses an app on a given day.
• Days / person (frequency) and Depth (responses per person for tools, hours per person for web apps).
• By department uses the directory. People the directory does not know sit under Not in the directory. Adoption against headcount needs a connected directory.

Seats and waste

For each subscription, a seat counts as used when its holder reported activity with a tool the subscription covers in the period. Unused seats are the seats paid for that nobody holds, plus held seats whose holder did not use a covered tool. Their cost is the seat price for the time involved, so it is money billed, not an estimate. The page checks that the seat costs it shows add up to the ledger’s seats total and says so under the calculation trail.

Time saved (estimates)

Time saved is never measured. It is:

time saved = Σ (count of each kind of work × minutes assumed for it) ÷ 60
value      = time saved × hourly rate (AI Code settings)

The kinds of work are AI responses and each type of agent action (file edit, shell command, git, search, and so on). Nothing is estimated until an administrator sets minutes: a kind left blank counts as zero. Suggested minutes are offered in the editor, but they are not used until someone saves them. Changing the assumptions needs the Change cost settings permission and is recorded in the audit log with the old and new minutes.

Estimates are labelled (estimate) wherever they appear, are shown with their assumptions, and are never added to spend.

AI responses and agent actions are counted separately. If both describe the same work in your organisation, set minutes for one of them only.

Calculation trail and export

How these figures are calculated lists every headline figure with its formula, inputs, source and basis (count, billed, estimate or assumption), each assumption with when it was last changed, and each subscription’s seat line.

Export downloads the report for the period as PDF or CSV, with the calculation trail and assumptions. CSV cells that look like spreadsheet formulas are quoted so a spreadsheet does not run them. Every export is recorded in the audit log as data access.

The API behind the page:

Route	Method	Permission
/api/adoption/summary	POST { timeLimit: { start, end } }	View costs
/api/adoption/export?format=pdf|csv&start=…&end=…	GET	View costs
/api/adoption/assumptions	GET / PUT { minutesPerAction: { file_edit: 3, … } }	View costs / Change cost settings

Use cases need activity provenance

Agent actions come from activity provenance. It is on by default for organisations created since it became an organisation setting. Older organisations keep their earlier state, and the page shows administrators a prompt to turn it on. Without it, only AI responses are counted.