Measure & expand
What to measure during the pilot, and when to add the next team.
What's built in, and what isn't
Built-in usage analytics Coming soon aren't available yet: there's no dashboard of searches, active users or trends. Everything on this page uses what ships today, plus a few checks you run yourself. Budget about 30 minutes a week.
What you can measure today
| Signal | What it tells you | Where to find it |
|---|---|---|
| Ledger topics recorded, by person and type | Whether the "record after" habit is forming, and in whom | The Ledger page, and each topic's page |
| Topics superseded | Whether people build on earlier decisions instead of contradicting them | The Ledger page, and each topic's page |
| Sources connected and fresh | Whether agents search current material | Sources, and Source health on the Overview page |
| People whose key was used | Who is connected and active | Last used on the Team page |
| Answers with a correct citation | Whether answers can be trusted | A weekly spot check |
| Repeated questions answered | Whether the team's common questions are covered | The question list from your use-case workshop |
| Time to answer | Whether it saves time | A before-and-after spot check |
| How people rate it | Whether they'll keep using it | A short survey |
Ledger activity
The ledger is your best adoption signal, because every record is attributed. Each topic records who opened it, with which agent and when. Each entry in its history records its author and time.
The Ledger page lists every topic in the selected namespace, 50 to a page, the most recently updated first. It shows how many topics there are, and the number follows the type and repository filters. Each row shows the topic's type, status and when it was last updated. A new entry moves a topic to the top, and so does being superseded. Archived topics aren't listed.
Once a week, in each namespace the pilot uses:
- Count the topics. Choose each type in turn, and note how many topics the page shows. The rise since last week is the number recorded, less any archived. On the Overview page, Decisions this week counts the decisions opened in the last 7 days.
- See who recorded them. Open each topic at the top of the list that was updated in the last 7 days. Its page shows when it was opened and by whom, and who wrote each entry.
- Count supersedes. Among those topics, count the ones with the status Superseded. Each one links to the topic that replaced it.
- Find stale incidents. Choose Incidents. An open incident whose Updated time is more than 7 days ago has had no new entry for a week. On the Overview page, Open incidents counts every open incident.
What to look for:
- Several people record topics, not one enthusiast.
- A mix of types. Only decisions, or only incidents, suggests the habit covers part of the work.
- Supersedes appear by week 4 or 5. None at all can mean people record contradicting topics instead of superseding the old one.
- Few near-duplicates. Topics that repeat older ones mean agents record without searching first.
Sources connected and fresh
The Sources page shows each source's status, when it last synced successfully, when it syncs next, and any error. The Source health panel on the Overview page lists each source's last successful sync and status, and a notice at the top of the page names any source that is failing. Both show only the namespace selected in the switcher at the top of the sidebar, so check each namespace the pilot uses. Aim for no source failing for more than a day, and every source synced within its schedule.
Who is active
The Team page shows a Last used time for each person: when their newest live key was last used. Count the people whose key was used this week. That's your number of active people. If someone keeps several keys, this can miss use of their older ones.
Two console figures to ignore for now
The Team page's Searches, 30 days and Ledger writes columns aren't recorded yet, so they show zero. The Activity panel on the Overview page shows sample data, and is marked Fixtures. Use the checks on this page instead.
Answer quality: citation spot checks
Each week, collect 10 answers from the pilot, for example in a shared channel or document. Open every citation in each answer and score the answer:
- Correct: the cited file, page, issue or topic says what the answer claims.
- Wrong: the citation exists, but doesn't support the claim.
- Missing: the answer has no citation.
Wrong citations usually point to a stale source or an agent that went beyond what it found. Missing citations usually mean the agent instructions need tightening.
Repeated questions
Keep the 10 questions your team asks most, from the use-case workshop. Every two weeks, ask each one through an agent, and note whether the answer was correct and cited. When a question fails, find out why: a missing source, a stale source, or a decision nobody has recorded yet. Then fix that cause.
Time to answer
Before week 1, time how long five common questions take the usual way. At weeks 4 and 8, time the same questions with an agent, including the time to open the citation. Compare the medians. It's a spot check, not a study, but it grounds the conversation in numbers you measured yourself.
A short survey
Run it before week 1 as a baseline, then at weeks 4 and 8. Keep it under 2 minutes.
text
1. In the last week, how often did your agent use Workstate before answering?
Never / Once or twice / Most days / Every day
2. When it gave a citation, how often was the citation right?
Rarely / Sometimes / Usually / Always / It didn't give citations
3. About how much time did it save you this week?
None / Under 30 minutes / 30 minutes to 2 hours / Over 2 hours
4. Did you find an earlier decision or incident that saved you redoing work? If so, which topic?
5. Did you record a topic this week? If not, what stopped you?
6. What's one question it couldn't answer?
7. How likely are you to keep using it? (1 = not at all, 5 = certainly)A weekly scorecard
Copy this into your team page or a spreadsheet. The targets are examples. Set your own in the launch plan.
| Measure | How | Target (example) | This week |
|---|---|---|---|
| Active people | Last used this week, on Team | Everyone in the pilot | |
| Topics recorded | The weekly ledger check | 2 per person | |
| People who recorded a topic | The weekly ledger check | Most of the pilot | |
| Supersedes | The weekly ledger check | At least one by week 5 | |
| Stale open incidents | The weekly ledger check | None | |
| Correct citations | Spot check of 10 answers | 8 of 10 | |
| Repeated questions answered | The question list, every two weeks | 8 of 10 | |
| Healthy sources | Sources page | None failing for over a day | |
| Survey score | Average of question 7 | 4 or more |
When to add the next team
Add the next team when all of these are true:
- The pilot meets its goals for at least two weeks in a row.
- The habit has spread. Most of the pilot, not only the champions, recorded a topic in the last two weeks.
- The sources are healthy, and each one has a named owner.
- The next team's material is ready. Its sources are available today, not coming soon, and your namespace plan covers anything sensitive.
- The next team has a champion, ideally mentored by one of the pilot's champions.
- Access is planned. You know which namespaces each person in the next team needs, and who, if anyone, should be an admin.
If the pilot misses its goals, read the signals before you decide. Stale sources and missing agent instructions are quick to fix. A team that doesn't use AI agents yet may have been the wrong pilot.
How to expand
- Run a use-case workshop with the new team.
- Decide whether the team shares a namespace with the pilot or needs its own, using the admin setup guidance.
- Invite the new team with the namespaces from that plan, and check their rows in the Namespaces column on Team.
- Reuse the onboarding kit, updated with what the pilot learned.
- Measure both teams with the same scorecard.
Add one team at a time, so you can tell what worked.