Employee monitoring for MSPs: what breaks at multi-tenant scale

The short version: employee monitoring tools are generally designed for a single organization with one administrator group, one billing relationship, and one set of employees. Every assumption in that sentence is wrong for an MSP. The failure is not that the product lacks features — it is that the unit of the product is one company, and your unit is a portfolio.

Problem one: one vendor account per client

The default deployment path for a single-tenant tool is a separate account per client. Each has its own login, its own settings, its own invoice, and its own support relationship. At two clients that is mildly annoying. At twelve it is a real operational cost:

• Your technicians hold and rotate credentials for a dozen separate portals
• Configuration drifts, because nothing forces two accounts to be set up the same way
• Offboarding a technician means touching every account rather than one
• You reconcile a dozen invoices instead of one
• Cross-client reporting is manual, because no view spans accounts

The fix is a product where the client is a first-class object inside one account: separated records, separated files, separated settings, one login for your team.

Problem two: cost that follows your clients' headcount

Per-monitored-user pricing means your input cost rises every time one of your clients has a good year. You did not do more work, and you cannot bill more for the same service without renegotiating, so the growth lands on your margin.

It also distorts which clients you offer monitoring to. Below roughly twenty employees the deployment effort exceeds what the attach earns, so smaller clients get quietly talked out of a service they asked for.

What actually drives your cost to serve a monitoring client is the number of your technicians who need a console and the support load of the rollout. Neither moves much when a client grows from thirty people to sixty. A billing model keyed to console access rather than headcount matches that reality. The arithmetic is worked through here.

Problem three: access scoping built for one company

Single-tenant tools model roles as admin, manager, and viewer within one organization. An MSP needs a different axis: this technician supports these four clients and must not see the other eight. Reproducing that with separate accounts technically works, but it means access control is enforced by which credentials someone happens to hold, which is not a control you can evidence to a client.

What you want is assignment: admins work across the account, managers see only the clients assigned to them, and each assignment is full or read-only.

What to check before you commit to a tool

• Can one login move between clients without signing out?
• Can a manager be scoped to a subset of clients, read-only?
• Does adding a client change what you pay?
• Can each client see their own name, logo, and colors?
• Does it deploy silently through the RMM you already run?
• Is there an administrative audit trail spanning all clients?
• Can a local administrator uninstall the agent when you need to support the machine?

The honest limitation

Multi-tenant design is not free of trade-offs. A product built for MSPs tends to be younger and shallower on reporting than one that has spent a decade serving enterprises directly. If a specific report drives your weekly workflow, verify it exists before you switch rather than assuming parity. SnitchOS is Windows only and signs in through Microsoft Entra only, which rules it out for mixed fleets and for clients who are not on Microsoft 365.

The point is not that multi-tenant products are better in every dimension. It is that the three problems above are structural, and no amount of report depth fixes them.