Employee Monitoring: Monitoring - Screenshots
Objective. Read the Screenshots page correctly and demo it without tripping the surveillance objection: name the grid, the per-user card, the viewer and its Live and Past controls, explain that capture is policy-driven and transparent, and use a screenshot only as evidence to investigate with context, never as a verdict on a person.
Screenshots is the most privacy-sensitive surface in the product, so the guardrail leads: screen captures are a policy-driven, consent-based, configurable signal that exists to answer a question with evidence, not to watch people. The page is a per-user grid of the latest captured screen images for the selected day; opening a card gives a larger viewer with Live and Past Recording modes. Everything on it is seeded demo data.
See it in the demo
What this page answers
Before anything else: screenshot capture is a policy-driven, transparent, configurable control. Whether screenshots are captured at all, for whom, how often, and who may view them is an administered choice the customer sets and tells employees about - it is not a blanket always-on camera. Position it that way first and the rest of the page is easy.
With that frame, the page answers for the team and day I picked, what was actually on screen when I need to look? An ops lead or investigator opens it when a flag elsewhere (a suspicious-activity signal, a security or compliance question, a disputed timesheet) needs visual evidence before any conclusion. It is reached from the Monitoring section of the sidebar; the sub-tabs across the top are Screenshots, Screen Recordings, Keystrokes, Sound Recordings. The date control (the demo sits on a fixed fictional day), prev/next arrows and a GMT timezone control set the scope, and a Search users box narrows to one person.
On the page, panel by panel
The grid. The body is a paged grid of per-user screenshot cards. Each card shows a thumbnail of that person's most recent captured screen, the user name, and a small green status dot (an online/last-seen indicator). The demo paged this as 1-20 of 37 users with a Show 20 / 30 / 50 per page control and page numbers at the bottom - so the grid is one card per in-scope person, not one per capture.
The viewer (open a card). Clicking a card opens a larger modal viewer. In the demo it opened in Live mode: a red Live dot, a full date-and-time stamp (for example Tuesday, Nov 03, 2026, 02:58:45 PM), the full-size captured screen image, and a Close button. Along the bottom are the person's avatar and name, a Stop Recording control, and a Past Recording / Live toggle. Live shows the current captured frame; Past Recording switches the same viewer to earlier captures for that person. The viewer is shared with the Screen Recordings tab, which is why the capture and playback controls look identical.
How it is used
This is not a browse-all-day screen; it is an evidence lookup. The routine is: a question arrives from somewhere else (an exception, a security alert, a client dispute), the investigator searches for the one person, opens their card, and reads the capture around the relevant time using the Live or Past Recording toggle. The decision made from it is narrow - does the visual evidence support or dismiss the flag - and it is made with the surrounding context (what the person was assigned, what the activity feed shows), never from the image alone.
The drill path: a screenshot is usually the end of a trail that started on Overview or Suspicious Activity, and it sits beside Screen Recordings (motion), Keystrokes (input) and Sound Recordings (audio/live) as the four capture surfaces an investigator can call on where policy allows.
How to read it right
One: a screenshot is a signal, never a verdict. A single captured frame is a moment out of context. It shows what was on screen, not why, not whether the person was doing legitimate work in another window, and not intent. Always pull the surrounding evidence before any conclusion about a person - that is the core interpretation check for this whole app.
Two: capture is governed, so coverage is partial by design. If policy does not enable screenshots for a team, or the agent was off or offline, there are no captures - absence of an image is not absence of work, and the green status dot only reflects connectivity. Three: the figures and images are seeded demo data on a fixed fictional date; the timestamps, user names and screen contents are illustrative, not a real person's day. Four: the Stop Recording control is a capture control, not proof of anything about the employee - do not read it as a disciplinary action.
How to demo and sell it
This is the page most likely to lose the room if you open on it cold, so lead with the guardrail, then show the capability. Say first: screenshots are a policy you set - what is captured, for whom, how often, and who can see it - and employees are told; this exists to answer a question with evidence, not to watch people. Only then open a card and show the viewer. Land one value point: when a real question arises - a security flag, a compliance ask, a disputed timesheet - you can see the evidence instead of guessing, inside an agreed boundary. Make the honesty move yourself before the prospect raises it: a screenshot is a prompt to investigate with context, never a verdict. The discovery question this page answers: today, when a genuine incident happens, can you produce the evidence to investigate it - and can you stand behind how you collected it? That second half is what wins a regulated RCM or BPO buyer who fears legal and cultural exposure more than they fear blind spots.
Honest limits
Screenshots prove what was on a screen at a captured moment - they do not prove productivity, output, intent, or that unobserved time was wasted. The capture cadence, retention period, which teams are in scope, and who may view images are all customer-configured and jurisdiction-dependent; confirm the exact modes, retention and access controls with product before quoting any of them, and never imply continuous or covert capture. Whether Live view and Stop Recording behave in production as they do in this demo is SME-validation-pending. Employee communication (telling people in writing what is captured and why) is a real adoption and compliance dependency, not a nicety. Treat every image, name and timestamp here as seeded demo data.
Interpretation check
A captured screenshot is a policy-governed signal to investigate with context, not a verdict on a person: it shows what was on screen at one moment, not intent, not output, and not what was happening off-screen - and capture itself is a configurable, consent-based control, so a missing image means no capture, not no work.
In the field
For a regulated RCM operation like KnackGlobal (~6,000 seats), the win is not watching screens - it is being able to produce governed visual evidence for a genuine security or compliance incident, inside an agreed capture policy that compliance signed off and employees were told about. Demo it as evidence with boundaries, which is exactly the opposite of the incumbent-spyware fear.
Practical task
On the demo Screenshots page, open one user's card and identify, out loud, the four parts of the viewer (Live indicator and timestamp, the captured image, the Live/Past Recording toggle, the person's name and Stop Recording control). Then write the two sentences you would say to a prospect before opening any card: the capture-policy boundary, and the signal-not-verdict rule.
Self-check
A prospect says 'so this just lets managers spy on people's screens all day.' Reframe it in one or two sentences.
Capture is a policy the customer sets - what is taken, for whom, how often, who can view it - and employees are told; it exists to produce evidence for a specific question (security, compliance, a dispute), not to watch continuously. Lead with that boundary before showing a single image.
An investigator finds one screenshot that looks like a personal website. What is the correct next step?
Treat it as a signal, not a conclusion. Pull the surrounding context - the activity feed, what the person was assigned, other captures around that time - before any judgement. One frame out of context proves nothing about intent or the rest of the day.
A team has no screenshots for the selected day. What does that mean and what does it not mean?
It means no captures exist for that scope - most likely screenshots are not enabled for that team by policy, or the agent was off or offline. It does not mean no work was done. Absence of an image is a coverage fact, not evidence about the employee.
What are the two modes in the screenshot viewer and what does each show?
Live shows the current captured frame for that person (with a red Live indicator and timestamp); Past Recording switches the same viewer to earlier captures. The viewer is shared with the Screen Recordings tab.
Why do you raise capture policy before you open a single card in a demo?
Because the buyer's real fear here is legal and cultural exposure. Agreeing the policy, access and employee communication first answers that fear and earns the right to show the capability; opening on screenshots cold loses the deal on trust.
Verified vs demo. The Screenshots grid, per-user cards with name and status dot, pagination (1-20 of 37), the Search users box and the viewer with its Live and Past Recording toggle and Stop Recording control were all read live on the demo at /monitoring/screenimages. All images, names, timestamps and the fixed date are seeded demo data. Capture cadence, retention, in-scope teams, who can view images, and whether Live and Stop Recording behave this way in production are customer-configured and jurisdiction-dependent - confirm the real behaviour and entitlement with product.