Work Output: Transactions
Objective. Filter the transactions view to a team, process and period, and read a completed-work count as volume in a specific mix - not as value, quality or productivity.
Transactions answers 'what completed work actually got done, and can I trust the count?' It is the raw material of every downstream number, so it is the first place a CSM checks coverage and a rep shows that output is being counted at all.
See it in the demo
What this screen answers
Sales opens Transactions to make 'completed work' tangible - individual units of work the system counted, not an abstract KPI. CSMs open it to sanity-check coverage: is the work that the customer actually completes showing up here, and at the right grain? It is the evidence layer beneath attainment, quality and cost.
The task
Scope to one team or process and one period so the count is interpretable. Look at the composition of the transactions - the types and complexity present - not just the total. For a CSM, the real task is a coverage check: compare what you see against what the customer says they complete, and flag any manual or off-system work that is not appearing. For Sales, pick one representative unit and walk it as the start of the time-to-outcome chain.
How to read it
A transaction count is completed-work volume in one mix, full stop. It is not value, not quality, and not a productivity score - ten simple units are not ten complex ones. The classic misread is comparing two totals across different work types or periods and concluding one team did more; that comparison is invalid until type, complexity and period are aligned. A high count can also hide rework or low-quality output, which only the quality screen filters.
Honest limits
Counts are only as complete as the sources feeding them. If completed work happens off-system or is defined loosely, the total is understated or inconsistent and every derived figure inherits the gap. This screen does not prove what 'completed' means for the customer or which systems are wired in - confirm completion definitions and source coverage with product before trusting a total as the customer's real volume.
Interpretation check
A transaction total is completed-work volume in one mix - never read it as value, quality or productivity, and never compare two totals until work type, complexity and period are aligned and coverage is confirmed.
In the field
In RCM, 'claims worked' as a raw count is the number incumbents quote; Work Output's job is to show whether those were clean, complex and counted completely - the difference that wins the displacement argument.
Practical task
Filter to one team and period, note the complexity mix, and write a two-line coverage finding: what the count represents and one source gap you would confirm with the customer before trusting it.
Self-check
Team B shows twice the transactions of Team A. Underperforming A?
Unknown. Raw counts across different work types, complexity, tenure and period are not comparable. You must normalise before any ranking, and even then check quality - fast-but-wrong inflates a count.
Why is this the first screen a CSM validates?
It is counted-work coverage. If completed work is uncounted or defined loosely, output, output-per-hour and cost-per-unit are all distorted. Coverage underpins everything downstream.
A high count looks like a strong team. What could you be missing?
Complexity mix and quality - a high volume of simple or reworked units is not strong delivery. The count needs the complexity and quality context before it means anything.
Verified vs demo. Screen is live in the demo at https://work-output.demo.timechamp.io/#/transactions; exact controls, labels and on-screen figures are SME-validation-pending.