Employee Monitoring: Monitoring - Keystrokes
Objective. Read the Keystrokes page and handle the single most sensitive capture in the product with care: name the table and its columns, explain that keystroke capture is policy-driven, consent-based and configurable, read it as a signal to investigate with context rather than a verdict, and know when to say it is off by policy.
Keystrokes is the most privacy-sensitive surface in the whole platform, so the guardrail is not a footnote - it is the feature. Keystroke capture is a policy-driven, consent-based, configurable and often deliberately disabled control that exists to answer a narrow security or compliance question with evidence, never to read what people type for its own sake. The page is a searchable table of keystroke events; in the demo it held no rows for the selected day, which is itself the honest default.
See it in the demo
What this page answers
Lead with the guardrail hard, because this is the capture buyers fear most: keystroke logging is an administered, consent-based, configurable control that many customers leave off by policy, and where it is on it is scoped, disclosed to employees, and used only to answer a specific security or compliance question. Say that before you say anything else.
With that frame, the page answers for the team and day I picked, what text input was captured where policy enables it, so a genuine incident can be investigated? It is reached under Monitoring; the sub-tabs are Screenshots, Screen Recordings, Keystrokes, Sound Recordings, with the same date, prev/next and GMT controls. In the demo on the fixed fictional day the table showed No data available - no captured keystrokes - which is exactly what a correctly scoped, policy-off configuration looks like, and a useful thing to show honestly.
On the page, panel by panel
The controls. Above the table: a record count (in the demo, Showing 20 of 0 records), a Search box, and a Show Symbols toggle that controls whether special and modifier keys are rendered alongside typed characters.
The table. One row per captured keystroke event, with four columns:
- Date & Time - when the input was captured.
- Activity - the application or window the input occurred in (context for what was being typed into).
- Computer - the device that captured it.
- Keystrokes - the captured input itself, with symbols shown or hidden by the toggle.
At the foot is a Show 20 / 30 / 50 / 80 / 100 per page control and pagination (in the demo, 0-0 of 0). The four columns are the whole anatomy: each event ties captured input to a time, an app context and a device.
How it is used
This is a targeted investigation surface, not a routine report, and in many deployments it is simply not used because the policy keeps it off. Where it is enabled, the routine is: a serious signal arrives (a suspected data-exfiltration attempt, a credential-sharing or compliance incident), an authorised investigator searches for the person or the time window, and reads the captured input only in the context of the Activity and Computer columns - what was being typed, into which application, on which device - alongside the matching screenshot or recording. The decision is narrow and the evidence is corroborated across surfaces, never read from the Keystrokes column alone.
The drill path: keystrokes corroborate a signal that started on Suspicious Activity or Behaviors, and sit beside Screenshots and Screen Recordings as the capture surfaces an authorised investigator can combine where policy allows.
How to read it right
One: captured keystrokes are a signal to investigate with context, never a verdict. Raw input is easy to misread; the Activity and Computer columns are what make it meaningful, and even then it corroborates, it does not convict. Two: an empty table usually means capture is off by policy, which is the common and correct default - read No data available as a configuration fact, not as proof that nothing was typed. Three: Show Symbols changes presentation, not substance - hiding symbols does not remove the capture, it only changes the rendering. Four: this is the capture most constrained by jurisdiction - in some regions keystroke logging is restricted or prohibited, so what is permissible is a legal question, not a product toggle. Five: any rows are seeded demo data on a fixed fictional date.
How to demo and sell it
Demo this one with restraint - over-showing it is how you lose a careful buyer. Lead entirely with the boundary: keystroke capture is the most sensitive control we have, it is off unless you deliberately enable it, it is scoped, disclosed to employees, and often limited to specific high-risk roles or investigations. Then show the page, and if it is empty, use the emptiness as the proof: on this configuration nothing is captured - this is what a responsible default looks like. Land one value point only: for the rare serious security or compliance incident, authorised investigators can corroborate input with the application and device context, inside a policy your compliance team owns. Discovery question: do you have, or does your regulator require, a controlled way to investigate a suspected data or credential incident - and could you defend how you gathered that evidence? If a prospect wants keystroke logging switched on broadly, that is a flag to slow down and bring in compliance, not a quick win.
Honest limits
Captured keystrokes prove what characters were sent to an application on a device at a time - not intent, not meaning without context, and not that any wrongdoing occurred. Whether keystroke capture is available at all, for which roles, retention, who may view it, and whether it is lawful are customer-configured and heavily jurisdiction-dependent - this is the capture most likely to be restricted or prohibited, and the specifics must be confirmed with product and the customer's legal or compliance function before any claim. Never present keystroke logging as a routine productivity feature or imply it is always on. The exact behaviour of the Search and Show Symbols controls and the real column semantics are SME-validation-pending; the demo showed the table empty on the selected day. Any rows are seeded demo data.
Interpretation check
Captured keystrokes are a policy-governed, jurisdiction-constrained signal to corroborate with context (the Activity and Computer columns and other capture surfaces), never a standalone verdict - and an empty table normally means capture is off by policy, which is the common and correct default, not proof that nothing was typed.
In the field
For a regulated RCM buyer like KnackGlobal, position keystrokes as a controlled, compliance-owned incident capability for the rare serious case (suspected data or credential incident), explicitly off by default and disclosed to employees - the opposite of the blanket keylogging that the ProHance-style spyware fear is built on. The responsible default is the selling point.
Practical task
On the demo Keystrokes page, name the four table columns and the two controls (Search, Show Symbols), and note that the table is empty on the selected day. Then write the opening you would use with a careful buyer: the off-by-default boundary, why the empty table is a feature not a gap, and the one narrow use case you would stand behind.
Self-check
A prospect asks you to turn on keystroke logging for everyone. What is the right response?
Slow down and bring in compliance. Keystroke capture is the most sensitive and most jurisdiction-constrained control; it is normally off, scoped to specific high-risk roles or investigations, disclosed to employees, and sometimes legally restricted. Broad always-on logging is a red flag to confirm lawfulness with product and legal, not a quick win.
The Keystrokes table shows No data available for the day. What does that most likely mean?
That keystroke capture is off by policy for this scope - the common and correct default - so nothing was captured. It is a configuration fact, not evidence that nothing was typed. Read it that way and, in a demo, use it as proof of a responsible default.
Name the four columns and explain why Keystrokes cannot be read on its own.
Date & Time, Activity (the application/window context), Computer (the device), and Keystrokes (the captured input). Raw input is meaningless and easy to misread without the Activity and Computer context, and even then it corroborates a signal rather than proving intent - so it is read with other evidence, never alone.
What does the Show Symbols toggle change, and what does it not change?
It changes whether special and modifier keys are rendered alongside typed characters - a presentation choice. It does not change what was captured; hiding symbols only alters the display, it does not reduce the capture.
Why is this the module where you demo with the most restraint?
Because keystroke logging is the capture buyers fear most and the one most constrained by law. Over-showing it confirms the spyware objection; leading with the boundary (off by default, scoped, disclosed, compliance-owned) and using the empty table as proof of a responsible default is what keeps a careful buyer's trust.
Verified vs demo. The Keystrokes table and its four columns (Date & Time, Activity, Computer, Keystrokes), the Search box, the Show Symbols toggle, the per-page control (20/30/50/80/100) and the empty state (No data available, 0-0 of 0) were read live on the demo at /monitoring/keystrokes on the fixed fictional date. Whether keystroke capture is available, lawful, for which roles, retention, and who may view it are customer-configured and heavily jurisdiction-dependent, and the exact control and column semantics are SME-validation-pending - confirm all of it with product and the customer's legal or compliance function. Any rows would be seeded demo data.