Work Output - Data and Setup Reference
Objective. Know what Work Output needs to produce correct numbers: the signals it depends on, the configuration and integrations required (at app-logic level, confirm-with-product for specifics), the other apps it leans on, and exactly what a CSM validates before trusting a figure - so recoverable, billed, collected and capacity value stay separable and no projection is mistaken for a measured result.
Work Output is only as good as what feeds it. This reference lists the data and config the app depends on and draws the line between what you can describe at app-logic level and what must be confirmed with product. It extends the app overview's validation routine into a checklist a CSM runs before any number enters a customer conversation, and it names the point at which the implementation specialist takes over.
See it in the demo
The data and signals it depends on
Work Output counts completed work and puts it in context, so it needs four classes of signal:
- Completed-work events (transactions) - a record of each unit of work completed, at a grain the customer can recognise. This is the raw material; everything else is derived from it. If a unit is not represented here, it does not exist to the app.
- Complexity and work-type attributes - what kind of work each unit is and how hard, so a count carries meaning and ten simple units are not read as ten complex ones.
- Standards (expected values) - the expected output per process and complexity band that attainment is measured against. Without an agreed standard, attainment is arithmetic without meaning.
- Quality signals - whether completed work met the required standard, so 'clean' output is real and output per hour is not inflated by fast-but-wrong work.
Cost and value sit on top of these: a cost basis and rates turn clean output into cost per clean unit, and value figures (recoverable, billed, collected, capacity) are only meaningful once the underlying output and quality are trusted. Confirm with product exactly which signals a given customer feeds and how each is sourced.
Setup, configuration and integrations (app-logic level)
Described at the level you can speak to without guessing specifics:
- Source integration for completed work - the systems of record that emit completed-work events have to be connected and mapped to the app's transaction model. Which systems, and how the connection is made, is confirm with product per customer - never assert a named integration or a mechanism you have not verified.
- Completion definition per process - the rule that says what counts as a completed unit. This is a configuration and an agreement, not a default, and it has to be set with the customer.
- Complexity model and work-type taxonomy - how units are classified and weighted. Treat the weightings as assumptions to be agreed.
- Standards configuration - expected values per process and complexity, governed rather than left at defaults.
- Quality signal wiring - where the quality verdict comes from (a quality process, a downstream check, or an integration). Confirm the source with product.
- Cost basis and rates - the cost model that drives cost per clean unit; always rebuilt on the customer's own rates, never the demo's.
Do not invent config screens, field names, connector names or toggles. Describe the logical requirement and route specifics to product or the implementation specialist.
Dependencies on other apps
Work Output stands alone but is far stronger in context, and some readings explicitly borrow from neighbours:
- Time and Activity supplies the paid-hours and utilisation denominator. The signature sales contrast - utilisation next to output attainment - needs Time and Activity for the utilisation side. Clean output per paid hour depends on a trustworthy hours figure from there.
- Work Understanding explains why output moves - waiting, rework, friction - where Work Output tells you that it moved and by how much. Root-cause narratives often hand off to Work Understanding.
- Value Leakage is where a recoverable opportunity is attributed, owned and tracked to verification. Work Output can surface a cost or output gap; Value Leakage governs whether any of it is recovered, and keeps recovered capacity distinct from cash recovered.
- RCM Operations connects an output or cost signal to a revenue-cycle outcome for an RCM customer.
These are complementary inputs and destinations, not a requirement to buy the whole suite - state independent value first, then incremental value, and never let a cross-app figure blur the four value types.
What a CSM validates before trusting the numbers
Run this before any Work Output figure enters a customer conversation:
- Completion definition - is 'a completed unit' stated exactly per process, and does the customer agree it? Loose here means every downstream number is loose.
- Counted-work coverage - does counted work match what the customer says they complete? Hunt specifically for manual or off-system work that is not appearing; document every known gap.
- Complexity and standards - are complexity weightings and expected standards agreed, credible and matched to the work, not defaults?
- Quality signal - is the quality verdict real and sourced, so 'clean' means something?
- Cost basis and rates - is cost built on the customer's own model and agreed rates before cost per clean unit is shown?
- Value-type integrity - for any value figure, is it labelled as recoverable, billed, collected or capacity, and is opportunity never shown as realised?
Escalate to the implementation specialist when: a source system cannot be mapped cleanly or completed work is structurally uncounted; completion or complexity logic needs a model change; the quality signal has no trustworthy source; or the cost model cannot be rebuilt on the customer's rates. Never paper over a data gap with a plausible demo value.
Interpretation check
Every Work Output figure inherits the trust of the signals beneath it - completed-work coverage, agreed complexity and standards, a real quality signal and the customer's own cost basis - so validate those first; and keep recoverable, billed, collected and capacity value labelled and separate, never presenting opportunity as realised.
In the field
For KnackGlobal, cost per clean claim only becomes credible once completed-claim coverage is confirmed (no off-system work uncounted), claim complexity and standards are agreed, the quality signal defines a clean claim, and cost is rebuilt on KnackGlobal's own rates - at which point it becomes the displacement figure, with recoverable opportunity still tracked separately in Value Leakage rather than booked as cash.
Practical task
For one process on a real or seeded account, write the data-setup validation sheet: state the completion definition, list the sources feeding completed work and one suspected coverage gap, note whether standards and complexity are agreed, identify the quality signal source, and state whether cost is on the customer's rates. End with a go/no-go line on whether cost per clean unit is safe to show, and one item you would escalate to the implementation specialist.
Self-check
A customer's cost per clean unit looks implausibly low. Which data dependencies do you check first, and why?
Counted-work coverage and the cost basis. A low cost per clean unit can come from uncounted work inflating the denominator-less picture or from demo/default rates rather than the customer's own model. Also confirm the quality filter is on, or raw output is masquerading as clean output.
Which app supplies the denominator for clean output per paid hour, and what does that mean for setup?
Time and Activity supplies paid hours and utilisation. Clean output per paid hour is only trustworthy if the hours figure is trustworthy, so the Time and Activity side has to be validated too - the output number alone is not enough.
A stakeholder asks you to name the connector that pulls completed-work events for their system. How do you answer?
Describe the logical requirement - completed-work events from their system of record mapped to the transaction model - and confirm the specific connector and mechanism with product. Never assert a named integration you have not verified.
When does a data issue stop being a CSM validation task and become an implementation-specialist escalation?
When a source cannot be mapped cleanly or completed work is structurally uncounted, when completion or complexity logic needs a model change, when the quality signal has no trustworthy source, or when the cost model cannot be rebuilt on the customer's rates. These are setup problems, not readings to validate.
Why is value-type integrity part of the data-setup check and not just a presentation rule?
Because whether a figure is recoverable, billed, collected or capacity depends on what it is sourced from and how it is defined. If the setup blurs those definitions, the separation cannot be enforced downstream - so it has to be validated at setup, with opportunity never defined or shown as realised.
Verified vs demo. The demo shows the model on a seeded dataset with plausible values; the customer's actual sources, completion definitions, complexity model, standards, quality signal, cost basis and rates are all confirm-with-product and must be validated and owned by the customer before any figure is trusted.