SightLift

How Tools works

The Tools tab is every AI skill your team actually uses, in one place — the capabilities you've published in SightLift, and the skills in use outside it. It's the readout: what your team runs, who it reaches, and what that work is worth. This page explains what each number means and where it comes from.

← How capabilities work

Tools is a readout, not a workbench. Nothing here changes your setup — you read it, then act from the Capabilities tab (publish, verify, retire) or your Action plan (the actions SightLift builds from what it found).

The two rooms

The tab has two sub-tabs, for two different readings:

Overview — the readout. What your team runs, what it's worth, what to add next. No toggles, no setup.
Departments — the analytics workspace. Team scores, who uses what by department, and groups of skills doing the same work.

Three kinds of thing, deliberately kept apart

Overview shows three lists, and the split matters: the difference between them is whether you can do anything about them, and how well we can measure them.

What you'll see	What it is	What you can do
SightLift capabilities	Skills your team promoted and published here, so they run as managed tools. SightLift serves them, so everything about them is measured — exact use counts, real people counts, realized labor dollars.	Manage them on the Capabilities tab; open a row for its detail and example uses.
Skills outside SightLift	Connectors and skills your team brought themselves that were never published here. We only observe these, so counts carry a `~` and dollars carry a `≈` with a basis you can hover.	These are the publishable ones — the list is ranked as a recommendation of what to add next.
Built-in tools in use	The tooling that ships with your team's AI assistant — file editing, search, the browser, and so on. Your team didn't build these and can't publish them.	Nothing — and that's why the list is collapsed and carries no action.

Why built-ins are shown at all. They're a large share of what your team runs, so leaving them out would make the totals look wrong. But they are in use, not a problem to fix: as the tab puts it, they "come with your team's AI tools rather than being something your team built, so there is nothing to publish. Shown for visibility." No dollar estimate is shown against them either — a saving implies a decision worth making, and there isn't one here.

Published capabilities — the measured list

The published table is the part of your toolbox SightLift runs, so it's the part we can count exactly. Four columns:

Capability — with the lane it sits on from your capability board, or In rollout when it's published but has no measured runs yet.
Usage — a small trend line: runs per week over the recent weeks we read.
People — distinct people using it.
Labor saved/mo — the realized labor value, or the word measuring when there isn't a figure yet. We'd rather say "measuring" than show you a number we can't stand behind.

If your plan includes the Capability workbench, a compact view of your capability board sits above the table — the same seven lanes, same names, same order as the Capabilities tab, with a one-line note under each (what your team added in the last 30 days, and improvements shipped). The three lanes with no figure of their own repeat that lane's own one-line hint from the Capabilities tab, word for word — so Needs attention reads drifted — re-verify or retire, which is what that lane holds. It used to read sensitive-work reviews underway, which described something else entirely.

Without the workbench, the board and the pipeline sentence in the summary above it are not shown, and the published table you're reading about here is unchanged: those are the capabilities SightLift is running for your team, which is what this page is a readout of. The Capabilities tab stays in your left rail either way, marked Not on your plan — open it and it explains what the workbench does and how to talk to us about it.

Opening a capability

Clicking a row opens its detail, which adds the things a summary can't carry:

Served suggestions taken up — of the suggestions that have had time to be acted on, the share your team actually took up, with the basis stated. Serves too recent to have had their chance aren't counted against it.
When it didn't land — kept as two separate counts on purpose, never averaged into one "reject rate". A dry-run error is the serve failing before anyone used it; a reported failure is someone using it and telling us it went wrong. The second is engagement, not avoidance.
Went another way — how often the team did, by hand, work a published capability already does. The most direct read on whether a published skill is being picked up.
Used by — departments, with counts. Never a list of names (see Privacy).
See example uses — single real examples, so you can check the work rather than take the number on faith.

Skills outside SightLift — what to publish next

This list is a recommendation, and it reads like one: "We detected N skills outside SightLift getting ~X uses/month across at least Y people. We recommend adding these to SightLift so the people already relying on them get verification, usage tracking and your policy checks — starting with…"

Grouped by connector, not by tool

Each row is a connector or server — the product your team connected — not each individual tool function inside it. A browser connector with eleven tools is one row, because those eleven are used together to do one job; listing them separately would suggest eleven decisions where there is one. "Who uses this skill" is answered at that same grain, as departments.

Why these numbers are approximate

We see this work happening but we don't run it, so the tab marks the difference rather than hiding it: counts read as ~, dollars read as ≈, and every estimate names its basis on hover. Where a skill has too little use to estimate honestly, the row says "too little use to estimate" instead of showing a figure. A skill earns exact numbers by being published.

Why publishing pays — and why the score follows

Publishing a skill your team already uses changes what happens around it. In the order that matters:

It gets verified. The work is proven against your team's real results before it's trusted, instead of being taken on trust.
It gets tracked. Use, adoption, failures and value become measured numbers instead of observed estimates.
Your policy checks apply wherever it runs. Until then it's observed only — brought by the team, outside those checks.
More people get it. A published standard is served to everyone doing that work, not just the person who set it up.
The labor value becomes real and measured — hours saved you can point at, priced at your own rate.

The score is the receipt, not the reason. Your AI-Use Score has a Reuse dimension that counts how much work runs on shared, verified tools. Publishing raises it because that's literally what Reuse measures — the points follow the benefit, they don't cause it. If a publish wouldn't help your team, the points aren't a reason to do it.

Consolidating duplicative tools

On the Departments view, Sprawl targets shows groups of skills doing the same work — usually the same product connected twice, or two teams that solved one problem separately. Consolidating them onto one published standard brings that work under verification and your checks. Each target names the connectors involved, how many people are outside the standard, and whether a published capability already covers it (covered) or not (no standard yet). Where one is already covered, the card links straight to that capability on your board.

Read the dollar carefully: it's value at stake, not a saving. The figure on a sprawl target is the labor value running through that work today. Consolidating three tools onto one standard standardizes that work — it does not recover it as cash. We label it "value at stake" for exactly that reason, and it should never be read as money you're about to get back.

Where SightLift has already turned a target into an action, the card links to it on your Action plan.

Departments

The Departments view answers "how is this landing across the org?" It has three parts:

Team scores — one AI-Use Score per team over the last three quarters, with the movement since last quarter. It's the same per-department number the score ribbon shows, never re-derived here. A team's card opens its workspace.
People by department — a grid of who uses each skill, as department head-counts.
A team's toolbox — per-department workspaces: what share of the team is on a published capability, what's published there, what outside skills they lean on, and what publishing the next one would get them.

Adoption is the only department-level measure

This is the one thing worth knowing before reading the grid. People counts exist per department; uses and dollars do not. We can tell which people are in which team, so a head-count per department is a real measurement. We can't attribute an individual use or an individual dollar to a department, so those figures stay company-wide — and every column that shows one says so, with a · tenant label and a tooltip repeating it. We'd rather label the grain than show you a company number dressed up as a team number.

When departments don't appear

Two different things can hold the Departments view back, and the tab tells you which one — because the fix is different:

"Add your org chart to see this by team" — or, if you've started, "N of M active people have no Department set."

We don't know enough people's departments to group by team at all — the same coverage rule the AI-Use Score uses to decide whether to group by team. What to do: set people's departments under Configuration → Company profile → Org & roles, and this fills in automatically.

"Your org chart covers the team, but no department has 3 or more people using AI yet."

This one is not a setup problem — your org chart is fine. Your teams are simply smaller than the reporting floor, and a breakdown below it would identify individuals rather than describe a team. What to do: nothing. Department workspaces open up automatically as teams grow past that, and everything measured is already on Overview, which reports at team level.

The same floor applies inside the view: a department is named on a skill only once at least three people there use it. Everyone below that rolls into a single unnamed "under privacy minimum" count, so the totals stay right without naming a small group.

Sensitive work and your policy checks

Publishing is also how work comes under governance. A published capability runs with your policy checks applied wherever it goes; a skill outside SightLift is observed only.

Separately, SightLift categorizes sensitive conversations into eight kinds: Legal · Finance · Personnel · Security · Strategic Internal · Strategic External · Personal · Health, union, religion. It checks whether the people handling the first six are cleared for that work. The last two are about a person rather than their work, so nobody is cleared for them. Clearances are set per person under Configuration → Company profile → Org & roles, and a person can hold several. There's also an explicit Not Sensitive answer, which is deliberately different from leaving the question blank: "Not Sensitive" is an answer (this person handles no sensitive work), while blank means we don't know yet and won't guess either way.

Clearance reviews are not a capability lane and do not show on the board — this page used to say they surfaced on the attention lane, which was never what that lane counts (see below). For how clearances feed the Governance dimension of your score, see How your AI-Use Score works.

Where the dollars come from

Every dollar on this tab is labor — time your team gets back, priced. The arithmetic is the same everywhere in SightLift, and it's deliberately boring:

time saved per use × uses = hours, then hours × your company rate = dollars.

The rate is one number an admin sets under Configuration → General → Monthly AI budget — a blended, fully-loaded figure (salary plus overhead). It's the single assumption behind every labor dollar here, which is why every figure that depends on it shows the hours behind it when you hover: "≈ N hrs/mo × $R/hr — your company rate, set in Configuration → General."

Two honesty rules we hold to. First, measured beats estimated, and the tab says which: published dollars are realized labor from counted uses; outside dollars carry ≈ and an estimate basis. Second, this is money your team could redirect — not money that appears in a bank account.

Why people and uses cover different spans

Deliberate, and worth knowing when two numbers on the page seem not to line up. Uses and dollars are the last 30 days, so a monthly figure is the window itself rather than something scaled up from a shorter one. People is a longer window, because a head-count needs enough span for a department to clear the privacy minimum and for a trend to have a shape at all. Every figure states its own span where it appears — hover a column heading, or open a row and read the labels under each number.

Privacy

Tools answers questions about work, not about people. That's a structural choice, not a setting:

"Who uses this skill" is answered as departments — always. There is no person roster on this tab, and no view that produces one.
Counts are floored at three. A department is named only when at least three people are behind the number; smaller groups collapse into one unnamed count. The floor is the same everywhere on the tab — grid cells, chips, list meta.
No individual scores. Team scores exist at team and company level only.
Receipts are examples, not rankings. "See example uses" opens single real conversations so you can check the work. It is never a leaderboard of who used what most.

For exactly what each telemetry level exposes and how to enable it safely, see Data access & privacy.

Common questions

Why is a skill I know we use missing? Most likely it hasn't reached the reporting floor yet, or its telemetry isn't connected. The tab shows a quiet note when it's only reading some of your team's tools, so the numbers are never mistaken for the whole picture.

Do I publish from this tab? No — Tools is the readout. Publishing, verifying and retiring happen on the Capabilities tab, and the actions SightLift builds from what it finds here land on your Action plan.

Is a long outside-skills list bad? No. It's a list of things your team found useful enough to go get — that's initiative, and it's the raw material for what to standardize next. The list is ranked so the top of it is where publishing pays most.

Why doesn't the labor saved match my finance numbers? Because it isn't a cash figure. It's hours × a rate you set, which measures capacity you can redirect. Change the rate in Configuration and every figure here re-prices with it.

Questions about a number on your own Tools tab? Contact your SightLift account team.