Work Understanding: Workflow standards
Objective. Read workflow standards as the agreed reference path and targets that conformance and step-time are measured against, confirm they are the customer's own agreed standards, and escalate setup.
Standards define the intended workflow and expected step times that other screens compare reality to. They answer 'what are we measuring deviation and performance against?' - the reference that must be the customer's own, not a default.
See it in the demo
What this screen answers
The customer question is: what is the agreed 'should be' - the intended path and expected timings - that we judge actual work against? This is a configuration and governance screen. Sales people show it to explain where conformance and step-time comparisons get their reference; CSMs review it because a standard that is not genuinely agreed makes every deviation finding arguable.
The value is a shared yardstick. Its correctness is entirely about ownership: a standard the customer did not set is a vendor opinion, and findings measured against it will be rejected the moment they are inconvenient.
The task
- Open the standards screen from the overview.
- Confirm the intended workflow path and any expected step times reflect what the customer has actually agreed - not a seeded default or an aspirational target no one signed off.
- Check that standards exist for the processes in scope, and note where they are missing.
- Treat authoring or changing standards as governed setup to escalate - who owns a standard and how it changes is customer policy, not a demo edit.
Describe standards by their role as the reference, not by invented control names or exact target values.
How to read it
A standard is the reference that gives conformance and step-time their meaning - deviation is only meaningful against an agreed 'should be'. The classic misread is reading a conformance or over-standard-time finding as fact when the standard itself is unvalidated or aspirational. Then the finding measures the standard's optimism, not the work.
Also watch stale standards: a reference set long ago may no longer match a changed process, so 'non-conformance' can simply mean the standard is out of date. Read who owns the standard and when it was last agreed before trusting any deviation built on it.
Honest limits
This screen does not prove a standard is correct or achievable; it holds whatever reference was configured. A demo's standards are seeded and do not represent what a customer will adopt.
Confirm with product how standards are authored, owned and version-controlled for a customer, and whether expected times are evidence-based or aspirational. Position standards review as the step that makes conformance findings defensible, and escalate authoring and governance rather than setting a customer's targets in a demo.
Interpretation check
A workflow standard is the agreed reference that conformance and step-time are measured against; if it is unvalidated, aspirational or stale, the deviation finding measures the standard, not the work. Ownership and setup are escalated.
In the field
An RCM 'claims should clear in 48 hours' standard that no operations lead agreed to will generate deviation findings that collapse in the first review - agreeing the standard first is what makes the conformance story stick.
Practical task
On the demo standards screen, pick one process, note its intended path or expected timing, and write the two questions you would ask the customer to confirm the standard is theirs and current before using any conformance finding built on it.
Self-check
A conformance finding shows heavy deviation. What must you confirm before trusting it?
That the standard it is measured against is the customer's own, agreed, and current. If the standard is aspirational or stale, the deviation reflects the standard's optimism or age, not the work.
Why is ownership the key question for a standard?
A standard the customer did not set is a vendor opinion, and every finding built on it will be rejected when inconvenient. Agreed ownership is what makes conformance findings defensible.
What does a stale standard do to conformance?
It can label a changed, improved process as non-conformant, because the reference no longer matches reality. Check when the standard was last agreed.
Should you set a customer's expected step times during a demo?
No. Authoring and governing standards is customer-owned, specialist setup to escalate - not a live demo edit.
Verified vs demo. Screen is live in the demo at /#/standards; exact controls and target values are SME-validation-pending and seeded, and how standards are authored, owned and versioned for a customer must be confirmed with product.