How should an enterprise software startup design usage and adoption reports for customer admins?

Illustrative situation: an early-stage startup sells contract-intake software to a freight company with 400 licensed seats. Ten weeks before renewal, the customer’s internal champion tells the company’s IT admin she needs usage numbers for her CFO. The admin opens the product’s settings and finds a member list with names and roles, and nothing else. The champion emails the startup’s customer success manager, who builds a spreadsheet by hand from raw events. In it, “active” means anyone who has ever signed in. The CFO asks how many seats nobody uses, and the spreadsheet cannot answer. The scene is invented. It shows the gap this guide covers: the startup collects usage data, but the customer cannot read it.

Humbleteam, a digital product design agency, publishes this guide. It covers who reads these screens, how to define “active,” seats against use, time ranges, exports, privacy limits and the empty state, with a worksheet and an invented worked example. Vendor behavior is described as of November 4, 2026 and can change. This is not legal advice: your lawyer and your customer’s lawyer decide what employee-monitoring rules require.

Who reads these screens, and what is each reader deciding?

Four people open usage screens, and each needs a different cut of the same data. This list is our reading, not research.

• The IT admin decides who gets a seat, who loses one and who needs retraining.
• The budget owner decides whether the contract renews at the same size.
• The internal champion has to show sponsors where the rollout worked and where it stalled.
• Procurement compares the order form with actual use at renewal.

Microsoft’s admin documentation describes the first reader’s job directly: its usage reports show who uses a service heavily and who barely uses it and might not need a license. The design consequence is three surfaces. Give the budget owner and the champion a summary page, the admin a per-seat list and procurement an export that opens in a spreadsheet.

What does “active” mean, and where should the screen say so?

Vendors define it differently. Slack’s metric guide counts a person as monthly active after they have read or sent a message in at least one channel or direct message over the current day and the preceding 28. Notion’s workspace analytics counts unique members who viewed a page. GitHub’s Copilot metrics page counts a daily active user as someone who interacted with Copilot that day, and places a user in an adoption cohort only after at least two active days in the trailing 28. Microsoft’s per-user last activity date is the most recent day of any intentional activity, whatever period the report covers. Atlassian’s user export gives a “last seen” date per product, and its page does not say what counts as activity.

Viewing and doing are different things. Someone who opens a dashboard every Monday is active under a viewing rule and may never create anything. Our suggestions: pick one counting action that reflects real work in your product, print the definition in one sentence beside every number, and keep it stable. If you must change it, treat it as a change customers will notice and give admins notice first. Our guide to shipping UI changes to enterprise customers covers how.

How should active users sit next to licensed seats?

Buyers ask for seats paid for against seats used. Show three numbers together: seats on the contract, seats assigned to a person and people active in the period. The middle number needs its own definition. Slack’s total members count, for example, leaves out deactivated members.

Microsoft’s Active Users report puts a last active date for each service in the same row as a flag for whether a license is assigned, so an admin can find people who hold a license and are not using it. Below the summary, offer the same thing as an inactive seat list: name, role, date the seat was assigned, last active date, sortable, with a remove action beside each row.

Reclaiming a seat is a billing event. Our suggestions: let the admin set the inactivity threshold at 30, 60 or 90 days, say what the person loses, show the effect on the next invoice and keep the seat restorable for a short window.

Which time ranges and freshness should the screens offer?

Offer presets and show a “data through” date on every screen. Microsoft offers 7, 30, 90 and 180 days and says reports typically appear within 24 to 72 hours. Google’s account reports show the latest available date under the graph heading. GitHub says a day’s data is available within two full UTC days after it closes.

History limits what a renewal conversation can use. Notion’s Members graph shows 90 days, analytics keep 365 days, tracking starts on the day a customer signs up for Enterprise and the page recommends regular CSV exports to keep older data. Our suggestion: keep daily rollups for the whole contract term plus the renewal notice period, and say so in the product.

What should exports, the API and scheduled email do?

Microsoft’s Active Users report has an Export button for CSV, and its overview points admins with thousands of users to Excel, Power BI or the Graph reports API. Google exports to Sheets or CSV, up to 100,000 rows. Slack’s Channels and Members tabs have Export CSV. GitHub offers a REST API, which it recommends for new integrations, and an NDJSON export for BI tools.

Scheduling is rarer in the pages we read. Losant’s usage reports let instance administrators schedule a CSV weekly, twice a month, monthly or by a custom cron string. Email recipients receive a download link, up to 10 addresses per report, and a callback URL is an alternative. The page advises scheduling a few hours after a day ends, because aggregations take time to roll up.

Our suggestions: send a link that expires, not an attachment; let the champion and a procurement contact be recipients without being admins; and make the export obey the same privacy settings as the screen. Microsoft’s setting for hiding user names also applies to its Graph and Power BI reports. Put the definition and “data through” date in the file itself or a companion file.

How much per-user detail should a report show?

Reports are about people, and defaults differ. Microsoft hides usernames, group names and site names by default to help companies support local privacy laws. A Global Administrator can show them if the organization’s privacy practices allow it, and doing so is a logged event in the Purview audit log. Slack restricts member analytics to Workspace Owners and Admins by default, lets owners limit or turn them off, and says its data is best used to understand a whole team, not to judge individuals.

Microsoft’s Copilot Dashboard settings go further: group-level metrics appear only for groups that meet a minimum size, 10 by default and never below five, and an exclusion list can hide people for legal, compliance or ethical reasons.

Works councils add another limit in some countries. Section 87(1), item 6 of the German Works Constitution Act, in the government’s English translation, covers introducing and using technical devices designed to monitor employees’ behavior or performance. Whether a usage report is such a device is a question for the customer’s lawyers, and other countries differ. A German customer may still need to switch off per-user rows before it can roll your product out.

Our suggestions: make aggregates the default, put per-user rows behind a separate permission and an organization-level switch, merge groups below a minimum size into one bucket, and log every time someone turns identifiable data on.

Which comparisons mislead?

Six comparisons tend to mislead. The first two are our suggestions. The rest draw on vendor notes.

• Percentages across teams of different size. Three of four is 75%, and 90 of 150 is 60%. Print counts next to percentages.
• A new team against an old one. Compare by weeks since go-live, not by calendar date.
• Totals with different scope. GitHub says organization totals are not directly comparable with enterprise totals, because users are attributed to every organization they belong to and enterprise pull request data is deduplicated.
• Blank read as zero. GitHub notes that proxies, firewalls, VPNs or disabled telemetry can leave detailed breakdowns empty. Show “not measured” differently from “0.”
• Rankings of people. Slack’s guidance points away from judging individuals, and a leaderboard invites exactly that.
• Cross-customer benchmarks. GitHub’s industry comparison is opt-in, off by default, and shares two summary scores per participant. Do not show “customers like you” without the same consent.

What should a new customer see before there is data?

A new customer’s first screen is all zeros, which can read as a broken product. Notion’s page says tracking starts the day of the Enterprise signup and nothing exists before it. Microsoft says data does not exist for all reporting periods right away.

Our suggestions: show “Collecting data since November 12; first weekly numbers on November 19.” Fill the page with numbers that exist on day one, such as seats assigned, invitations accepted and single sign-on connected. Hide percentages until a group is large enough to mean something. Offer a sample report with invented data, marked as a sample, so the champion can plan the first review.

Which fields does each usage screen need?

Illustrative worked example: a contract-intake startup and a freight buyer

Everything here is invented. Lumenfold is a fictional contract-intake startup. Harrow Freight is a fictional customer with 400 licensed seats. Ines Calloway leads customer success at Lumenfold, and Tomasz Reyes is Harrow’s IT admin.

Lumenfold defines active as “created, edited or approved a contract.” Its summary page reads: 400 seats licensed, 312 assigned, 241 active in the last 28 days, data through November 2. The 88 unassigned seats stay visible.

Tomasz opens the inactive seat list with a 60-day threshold and finds 38 assigned seats. He exports it, asks the 38 people’s managers whether anyone still needs one, and removes seats after a 14-day notice. Harrow’s German subsidiary has 9 users, below Lumenfold’s minimum group size of 10, so it appears inside “Other teams” and its per-user rows stay off until Harrow’s works council has reviewed them. Tomasz sets a monthly report, emailed as a link, to himself, the champion and a procurement contact. In the renewal meeting, Ines Calloway and the customer read the same screen. The scene stops before renewal. It shows both sides reading one definition on one screen.

Where do these defaults stop working?

The sources are vendor documentation. None of them measures whether usage screens change renewals or recover seats. Some vendor features depend on the plan: Slack’s Members tab needs a paid plan and Notion’s analytics are an Enterprise feature. These vendors run mature admin consoles, so a startup should start smaller, with the seat summary, the inactive list and a CSV export.

Source dates vary. Atlassian’s export page was last modified in 2021, and the GitHub and Notion pages show no date. Counts depend on instrumentation. GitHub’s page says Copilot Chat on GitHub.com and mobile are not included in its metrics, so use through an API, an integration or a mobile app may be missing from your own numbers unless you count it. A minimum group size also does not guarantee anonymity, because overlapping filters can narrow a group down. That caution is ours. Privacy law and works council rules vary by country, so involve counsel before promising a customer compliance.

What can you produce now?

Five things, before the next renewal cycle:

1. A one-sentence definition of “active” and the action it counts.
2. A seat summary showing licensed, assigned and active, with a data-through date.
3. An inactive seat list specification with an admin-set threshold and a removal flow.
4. A privacy table: who sees names, the minimum group size and how reveals are logged.
5. An export and schedule specification that includes the definition and a retention period covering the contract term.

If you want a design partner for these screens, our comparison of agencies that publish B2B SaaS platform cases shows what each one publishes.