Work Understanding: Privacy and evidence
Objective. Explain what evidence underpins findings and what privacy and access boundaries apply, so a customer can trust the data basis without overstating what is captured or who can see it.
This screen covers the evidence behind findings and the privacy, access and data-source boundaries around it. It answers 'what is this based on, and who can see what?' - the governance that lets a customer trust and defend the analysis.
See it in the demo
What this screen answers
The customer question is: what data are these findings built on, and what are the privacy and access controls around it? This is a governance screen that often decides whether a deal or an adoption proceeds. Sales people use it to answer the inevitable monitoring and privacy objection honestly; CSMs use it to validate that evidence, access scope and employee communication are set up defensibly.
The value is trust. A process-insight tool that cannot explain its evidence basis and its boundaries will stall on exactly the stakeholders - employees, works councils, security, legal - who can block it.
The task
- Open the privacy and evidence screen from the overview.
- Understand what evidence a finding rests on and how a reviewer can trace a finding back to its basis.
- Review the access and scope boundaries: who can see what, at what aggregation, for which processes.
- Treat specific privacy configuration, data-source scope and employee-communication policy as customer-owned governance to validate and escalate, not settings to assert or change in a demo.
Describe boundaries at the level of 'what is captured, at what aggregation, who can see it', not invented toggle names or policy specifics.
How to read it
Read this as the defensibility layer: a finding is only as trustworthy as the evidence you can trace it to, and only as adoptable as the boundaries around who sees it. The classic misread is overstating capture - implying the tool sees more than it does, or that managers can drill to an individual when the agreed scope is aggregated. Overclaiming here breaks trust faster than anywhere else.
The mirror misread is understating it and leaving a customer unclear on what is observed. The honest read is precise: state exactly what the evidence is, at what aggregation it is shown, and under whose access policy.
Honest limits
This screen does not set a customer's privacy posture by itself, and the demo's settings are not what any customer will run. What is captured, retained, and visible, and to whom, is customer configuration and legal-jurisdiction dependent.
Confirm with product and the customer's own security and legal owners what evidence, retention, aggregation and access actually apply. Never promise a specific privacy guarantee or capture scope as fact from the demo - position this screen as proof the product takes evidence traceability and access boundaries seriously, and escalate the real configuration.
Interpretation check
Findings are only as trustworthy as the evidence they trace to and only as adoptable as the boundaries on who sees them. Do not overstate capture or access; real privacy configuration is customer-owned, jurisdiction-dependent governance to escalate.
In the field
For a large RCM customer with a works council, the ability to show evidence traceability and aggregated-by-default access is what lets the deal clear employee-representation review - and overclaiming capture is what loses it.
Practical task
On the demo privacy and evidence screen, trace one finding to the evidence it rests on, note the aggregation it is shown at, and write the two boundary questions you would escalate to a customer's security owner before promising anything about capture or access.
Self-check
A prospect asks 'can a manager drill down to one employee's screen?'. How do you answer?
Only by reference to the agreed access scope and aggregation - never by overclaiming. State what the evidence and aggregation are, and confirm the actual access policy with product and the customer's security owner; do not assert a capability or a guarantee from the demo.
Why is overstating capture the most damaging misread here?
This is the screen that security, legal and employees judge. Implying the tool sees more than it does, or more granular access than agreed, breaks trust faster than any other error and can stall adoption.
What makes a finding defensible?
Being traceable to the evidence it rests on, shown at an agreed aggregation, under a known access policy. Traceability plus boundaries is what lets a customer stand behind the analysis.
Can you promise a specific privacy guarantee from the demo?
No. Capture, retention, aggregation and access are customer configuration and jurisdiction-dependent. Confirm with product and the customer's security and legal owners, and escalate the real setup.
Verified vs demo. Screen is live in the demo at /#/privacy; exact controls and settings are SME-validation-pending and seeded, and real capture, retention, aggregation and access for a customer are customer-owned, jurisdiction-dependent and must be confirmed with product and the customer.