Employee Monitoring: Activity - Apps & Urls
Objective. Read the Apps & Urls page across its four sub-views (By Application Groups, By Categories, Websites Visited, Applications Used), name the columns in each, drive the Productive/Non-Productive/Neutral filter, and explain why the classification - not the raw time - is the thing to validate.
Apps & Urls is the 'where did the time actually go' page: it aggregates captured time across the team into ranked tables of apps, sites, categories and groups, each with duration, idle time and a share percentage. It is one page with four lenses on the same question, and its whole meaning rests on how each app and site is classified - which is exactly the thing a customer configures.
See it in the demo
What this page answers
Apps & Urls answers for the chosen day, across the team, where did the time go by application and website, and how is that time classified? A manager opens it to see the tool reality of the work - which apps and sites the team actually spent time in - and a CSM opens it to check that those apps and sites are classified correctly for this customer. It is the evidence behind the productive/non-productive split on the Overview.
Controls: a Day period selector, the date, and a GMT timezone control at the top. The page is a tab with a dropdown offering four sub-views (below), and most sub-views carry a Productive / Non-Productive / Neutral classification filter (the 'select All' control) so you can isolate one class of time.
On the page, panel by panel
Apps & Urls is four ranked tables, one per lens, each sorted by how much time it accounts for.
By Application Groups - columns Application Group, Duration, Idle Time, Percentage. Groups are the broad buckets of tooling (for example 'Project Management Tools', 'Customer Relationship Management (CRM)', 'Communication and Collaboration Tools', 'Document Management and Storage'). Percentage is that group's share of the total captured time.
By Categories - columns Category, Duration, Idle Time, Percentage. A higher-level roll-up than groups (for example 'Communication', 'Development Tools', 'Business Tools', 'Social Media', 'Research'). This is the fastest read of the day's balance - how much went to communication versus build versus social.
Websites Visited - columns Productivity, Website, Duration, Idle Time, Percentage. One row per domain (for example stackoverflow.com, jira.com, github.com, twitter.com), each carrying its Productive/Non-Productive/Neutral pill. This is the site-level drill.
Applications Used - columns Productivity, Application, Duration, Idle Time, Percentage. One row per desktop/app (for example Zoom, Microsoft Teams, Google Chrome, Visual Studio Code, WhatsApp), each with its classification pill. This is the app-level drill.
Across all four, read Duration against Idle Time (open-but-unworked time sits inside Duration) and read Percentage as a share of the captured total, not of the paid day.
How it is used
The routine has two owners. A manager uses By Categories for the one-glance balance of the day, then drops into Applications Used and Websites Visited to see the specific tools and sites behind a category that looks high or surprising. A CSM uses the same tables as a classification-review surface: scan the top rows, confirm the customer's real work tools are classified Productive (a clearinghouse or payer portal must not sit in 'browsing'), and fix mislabels - because every productive percentage downstream is only as right as this mapping. The Productive/Non-Productive/Neutral filter lets either role isolate, say, all non-productive time and see exactly which apps and sites make it up.
The drill path: from an app or site here to the moment-by-moment context, go to Detailed Activity; for the input-intensity shape of the same day, go to Intensity Graph.
How to read it right
The central misread: a Non-Productive row is a classification, not a verdict. The pills on Websites Visited and Applications Used come from the customer's configured rules; a tool shows as non-productive only because it is mapped that way, and a legitimate work tool sitting in the wrong bucket will understate real work. In the demo the classification is illustrative. Second: Percentage is a share of captured time, not of the paid day - it tells you the mix of what was captured, so a coverage gap (unreporting agents) silently skews every percentage. Third: Duration is not active time - the Idle Time column is inside it. Fourth: the four lenses are the same time cut four ways, so do not add a Category total to an Applications Used total - that double counts. All durations, percentages and classifications here are seeded demo values.
How to demo and sell it
This page sells the 'tool reality' value and sets up the honest classification conversation, so demo By Categories first for the instant balance, then Applications Used for the named tools. Say: in one page you see where the team's time actually went - by category, by app, by site. Land one value point: for a leader who suspects work runs through tools they cannot see, this is the first evidence of the real tool landscape. Then make the trust move that wins regulated buyers - point at a Non-Productive row and say this label is a rule we agree with you, not a judgement the system makes; your clearinghouse and payer portals get classified as the productive work they are. That single sentence is the answer to 'this is spyware' and the reason to run the classification review in onboarding. Discovery question: do you actually know which applications and sites your work runs through today - and would your current tool classify your domain systems correctly?
Honest limits
Apps & Urls shows where captured time went and how it is labelled - it does not show whether the work in those tools was any good or produced the expected output (that is Work Output), and it is only as complete and as meaningful as agent coverage plus classification quality allow. The productive/non-productive/neutral mapping, the group and category taxonomy, and the idle thresholds are all customer-configured; defaults will mislabel domain-specific tools until reviewed - confirm the real setup with product. Whether site-level URL capture is enabled depends on the customer's policy, jurisdiction and plan. Treat every duration, percentage and label here as seeded demo data, not a customer result.
Interpretation check
Every Productive / Non-Productive / Neutral label on Apps & Urls is a customer-configured classification of a tool, not a verdict the system reaches - so a non-productive row flags a tool mapped that way, never proof that no useful work was done; and each Percentage is a share of captured time, so coverage gaps skew it.
In the field
For KnackGlobal (RCM, ~6,000 seats), this is the page that proves the classification argument against a crude incumbent: domain systems like clearinghouse and payer portals are classified as the productive work they are, so the productive split means something. Lead the CSM onboarding review here.
Practical task
On the demo Apps & Urls, write the day's tool reality in four lines: the top two Categories by share, the single highest Application and highest Website with their Duration and classification, one row you would question as possibly mislabelled for an RCM customer, and the sentence you would say to frame a Non-Productive label honestly.
Self-check
Name the four sub-views of Apps & Urls and the one thing each ranks.
By Application Groups (broad tooling buckets), By Categories (higher-level roll-up like Communication or Development Tools), Websites Visited (per-domain), Applications Used (per-app). Each ranks time by Duration and shows a Percentage share of the captured total.
A CSM is onboarding an RCM customer. Why is this the first page they review, and what are they checking?
Because the productive percentages everywhere downstream depend on this mapping. They scan the top apps and sites and confirm the customer's real work tools - clearinghouse, payer portals - are classified Productive, not left in a default 'browsing' bucket, and fix mislabels before anyone reads a split.
Why should you not add a By Categories total to an Applications Used total?
They are the same captured time seen through two lenses, not separate pools of time. Adding them double counts. Each view is a different cut of the one day's captured total.
The Percentage column - a share of what, and why does that matter?
A share of captured time, not of the paid day. So an agent-coverage gap (unreporting seats) silently skews every percentage, which is why coverage is checked before any mix is trusted.
A manager wants to act on a high 'Social Media' category. What is the honest next step on this page?
Drop into Websites Visited and Applications Used to see the specific sites and apps behind it, check they are classified correctly, then investigate with context - never present the category figure as proof of time wasted, since labels are configurable and it is a share of captured time.
Verified vs demo. The four sub-views and their columns were read from the live demo - By Application Groups (Application Group, Duration, Idle Time, Percentage) at /employeemonitoring/activity/app/applicationgroups, By Categories (Category, Duration, Idle Time, Percentage), Websites Visited (Productivity, Website, Duration, Idle Time, Percentage) and Applications Used (Productivity, Application, Duration, Idle Time, Percentage), plus the Productive/Non-Productive/Neutral filter; all durations, percentages and classifications are seeded demo data, the classification mapping and taxonomy are customer-configured, and whether URL-level capture is enabled depends on the customer's policy, jurisdiction and plan - confirm with product.