DEV Community: iMonitor Software

An employee monitoring notice your team can actually read

iMonitor Software — Sat, 24 Oct 2026 04:28:52 +0000

When a company tells staff that work computers will be recorded, the obstacle is rarely the intention. It is the wording.

"The company may monitor systems as necessary" answers none of the three questions people actually ask: what is seen, who sees it, and how long it is kept.

The seven parts

Purpose — one, not three.
Scope — which devices, which departments, how many.
Data recorded — named specifically, not "activity data".
Data not recorded — say it out loud.
Who can access — by role, not "management".
Retention period — how long, and what deletes it.
Contact point — where objections go.

The part that changes the reception

The list of what is not recorded is the one that does the work. It turns the notice from a warning into an explanation, and it forces the internal conversation most deployments skip: do we actually need this field?

In practice that list often includes keystroke content (counting how much is typed is different from recording what is typed), personal-use applications, and break periods.

Common mistakes

"As necessary" instead of a list.
Omitting the exclusion list entirely.
Naming a department for access instead of a role.
A retention period with no deletion step behind it.
A contact point that is a mailbox nobody reads.

Keep the notice and the configuration together

A policy that promises something the software does not do is worse than no policy, because it documents the gap. If the notice says screenshots are off, the product needs a way to keep them off — per team, not globally.

That is the practical test for any platform you evaluate: can a narrow promise stay narrow in the configuration?

General information, not legal advice. The rules differ by jurisdiction; confirm the local position with a professional.

iMonitor EAM is the on-premise edition: the server and database stay inside your own network, and every module switches on independently, so a narrow scope stays narrow. Product page

Time tracking vs employee monitoring: they are not the same purchase

iMonitor Software — Sat, 24 Oct 2026 04:28:21 +0000

Buyers arrive at this question after a bad meeting: someone asked for "monitoring", someone else heard "time clock", and nothing was decided.

The two are different products, bought for different reasons, and governed by different rules.

The difference in one line each

Time tracking answers: how long did work happen, and when. Typical driver: a legal obligation to document working time, payroll, or client billing.
Employee monitoring answers: what happened on the device while work was happening. Typical driver: a security incident, a productivity concern, a process problem.

The rule that settles most arguments

Time tracking is something you owe to the record. Monitoring is something you have to justify.

If the justification takes more than one sentence, you probably do not need the second one yet.

Four situations

You must document working time. Time tracking, scope it to hours. Do not let it drift into activity recording because the platform can.
You had a data incident. Monitoring, scoped to the incident and time-boxed. When the investigation closes, the scope closes with it.
You suspect the work is not happening. Check the operational indicators first — delivery against commitments, time stuck waiting, rework count. In most cases the answer is in the queue, not on the desktop.
You need both, for different groups. One platform, separate configuration per group. This is where module independence stops being a feature and becomes the reason the deployment is defensible.

The mistake

Buying the full feature set "so it is there if we need it", then leaving collection on. Capability you do not use is fine. Collection you do not need is the liability.

General information, not legal advice. The rules differ by jurisdiction; confirm the local position with a professional.

iMonitor EAM is the on-premise edition: the server and database stay inside your own network, and every module switches on independently, so a narrow scope stays narrow. Product page

Twelve checks before you buy employee monitoring software

iMonitor Software — Sat, 24 Oct 2026 04:16:15 +0000

Most buying mistakes in this category happen before the demo, not during it. By the time a vendor is showing you screenshots, the decisions that matter have already been made — or skipped.

Here are twelve checks, in the order the problems usually appear.

Legal and organisational

Can you state the purpose in one sentence? If the sentence needs a comma to hold two purposes, it is two projects.
Is the notice written before the installation date? A notice written afterwards is a reconstruction.
Is the role of employee representatives confirmed? In many jurisdictions there is a consultation or co-decision right. Confirm your own country's rule before ordering.
Is there a named person accountable for the data? Not a department. One person who can answer "who looked at this record, and why".

Technical

Can each module be switched on independently? Screenshots, keystroke activity, site categories, file access and working time should not be one switch. Otherwise you cannot implement a narrow notice.
What happens offline, and where does the data sit? Local recording with later upload is reasonable — but there needs to be a cap and an encrypted or deleted local cache after sync.
Is there a real self-service view? Employees seeing their own records changes the tone of the whole deployment. A product that treats this as an add-on was designed for one-way observation.
Are uninstall and offboarding documented? Ask for the procedure: removal, the leaver's records, department closure. "Delete the folder" is not a procedure.

Data governance

Are access rights granular, and is every view logged? Trust is lost to an unnecessary glance, not to malice. Role-based rights plus an access log make that answerable.
Is retention enforced by the system or by people remembering? Prefer the one that deletes on a schedule.
Can you export and then leave? You should be able to take your own records out in a usable format, and terminate without losing them.

Vendor

Will they say no? The most useful signal in this category: a vendor who explains why a request is disproportionate. If everything is "we can do that", the tool eventually gets configured into a problem.

If you keep only three

Independent modules, granular access with logging, and system-enforced retention. Those three decide whether the rest of your policy can actually be implemented.

General information, not legal advice. The rules differ by jurisdiction; confirm the local position with a professional.

iMonitor EAM is the on-premise edition: the server and database stay inside your own network, and every module switches on independently, so a narrow scope stays narrow. Product page

Five ways to measure remote productivity without monitoring anyone

iMonitor Software — Sat, 24 Oct 2026 04:15:40 +0000

"We cannot see productivity, so we are going to install monitoring."

That sentence comes up about once a week in conversations with operations leads, and it usually produces the opposite of what was intended. Monitoring raises the volume of records, not the results. And the more you record, the more the team works for the record instead of for the work.

Here are five indicators that actually show how a distributed team is doing. None of them requires recording anyone.

1. Delivery against commitments

Did the thing that was promised ship on the date it was promised? Not "was the person busy" — did the commitment hold. This is the only indicator that survives contact with a customer.

The useful part is not the percentage. It is the list of commitments that slipped, and the reason attached to each.

2. Time stuck waiting

How long does a task sit while someone owes a reply? This measures the organisation, not the individual. In most teams I have looked at, this is where the lost week actually goes — not in idle time, but in queues nobody owns.

3. Focus time outside meetings

The calendar is more accurate than any screenshot. If a team has no block of two uninterrupted hours in a week, the problem is scheduling, and no amount of activity data will fix it.

4. Where requests come from

Every question concentrated on one person is an early warning. If all decisions route through a single head, that person's holiday is a business continuity risk — and the team's apparent slowness is actually a bottleneck in one seat.

5. Rework count

How many items came back for a second pass? A high rework count usually points to an unclear instruction, not an idle team. Fixing the brief is cheaper than watching the desktop.

Run it in 30 minutes a week

Start of the week, 15 minutes: agree the commitments, in writing.
Midweek, 5 minutes: what is blocked and who owes the reply.
End of the week, 10 minutes: put commitment and result side by side.

That is the entire operating rhythm. It produces a conversation about the work, which is what the monitoring request was actually asking for.

When recording is genuinely justified

Sometimes it is: a data incident, a regulated environment, a client that requires documented working time, or a specific investigation. The difference is scope. A justified collection is narrow, time-boxed, and written down before it starts — not a platform-wide default left running because it was easy to switch on.

If you do end up choosing software, the questions worth asking are in twelve checks before you buy.

General information, not legal advice. The rules differ by jurisdiction; confirm the local position with a professional.

iMonitor EAM is the on-premise edition: the server and database stay inside your own network, and every module switches on independently, so a narrow scope stays narrow. Product page