A 40-person services company in Pune signs a banking client. Buried in annexure C of the MSA is a security schedule: session logging on any machine touching client data, retention for 18 months, quarterly audit evidence.
Nobody on the sales side read annexure C.
Six weeks later the delivery lead is trying to work out whether that means the four developers on the account, or everyone, and whether the tool they already use for utilisation counts. This is the most common way agencies end up buying monitoring software: not because they wanted it, but because a client's legal team decided for them.
It is worth getting this right, because the default response — apply the strictest client's terms to the whole company — is expensive and quietly corrosive.
Read the security schedule before you shortlist
Your client contracts set a floor. Everything above that floor is your choice, and it is worth treating it as one.
Look for four things in the MSA: what must be logged, how long it must be retained, who can audit it, and which machines it applies to. That last one is where most of the money is. A schedule that says "systems processing Client Data" covers four laptops. A schedule you have interpreted as "all company systems" covers forty.
If the clause is ambiguous, ask. Client security teams answer scoping questions readily and it costs you nothing. We have seen procurement conversations where the client's own answer was narrower than what the vendor was proposing to sell.
Two tools, scoped separately
The pattern that works:
Meet the client mandate — recording, DLP, whatever annexure C says — only on the accounts that need it. Run something much lighter across the rest of the business for the questions you actually have day to day.
Those questions are usually about staffing, not behaviour. Which accounts are absorbing more hours than they were scoped for. Whether the team that keeps missing estimates is overloaded or badly briefed. Whether you can take the next project without hiring.
None of that needs screen recording. All of it needs decent activity data.
Utilisation is the metric agencies get wrong
Every services business tracks utilisation. Most track it in a way that produces bad decisions.
The classic version is billable hours as a percentage of capacity, reviewed monthly, per person. It tells you whether people are assigned. It tells you nothing about whether the assignment is working, and it creates an incentive to look busy that is particularly toxic in a business that sells expertise.
Pair it with focus time and it starts being useful. A developer at 95% utilisation with fragmented days is a scheduling problem — too many accounts, too many context switches, and the cost of that switching is real and mostly invisible in a timesheet. The same person at 95% with three-hour blocks is genuinely at capacity.
The two look identical on a utilisation report and mean completely different things.
What to watch on multi-account teams
- People split across three or more accounts. This is the single most reliable predictor of slipping estimates, and it is a staffing decision you can reverse.
- Escalation load landing on the same two seniors every month. Invisible in utilisation, obvious in after-hours patterns, and a burnout signal in a sector where replacing a senior engineer costs more than a year of tooling.
- Time going to internal tooling and process rather than client work. Sometimes that is investment. Sometimes it is a broken deployment pipeline nobody has costed.
The India-specific layer
If you are an Indian services company, you are working two compliance regimes at once and they are easy to confuse.
For your client's data you are typically a Data Processor, and your obligations come from the contract. For your own employees' data you are a Data Fiduciary under the DPDP Act, with duties that exist whether or not any client asked for them: notice, purpose limitation, minimisation, retention limits, and a working grievance route. Full compliance is due 13 May 2027, and the DPDP guide covers what that actually requires.
The trap is assuming the client's security schedule discharges your employee obligations. It does not. Recording your employees because a client's contract told you to is still your processing, and you still owe your team notice for it.
Indian agencies also have a straightforward commercial reason to prefer INR-billed tooling: no FX spread on renewals, GST handled properly, and no card-fee leakage on a per-seat product you will hold for years. The India comparison covers the field.
Outside India
The structure is the same everywhere; the legal layer changes. EU and UK agencies need a lawful basis and usually a DPIA for anything heavier than metadata — see the GDPR checklist. US agencies face state-by-state notice rules, covered in the state guide. None of that changes the scoping advice: read the schedule, scope narrowly, run something lighter everywhere else.
What we'd actually recommend
If your MSAs mandate recording or DLP, buy a tool that does that, and put it only on the accounts that require it. Teramind is the honest choice at that end.
For the rest of the business, activity metadata is enough — app and category usage, focus time, meeting load, capacity across accounts. That is what ProdView does, at ₹399 or $4.99 per user per month, free for three seats, on Windows, macOS and Linux. We do not do session recording or DLP, and if annexure C says you need those, we are not the answer for those seats.
Start by reading the schedule. Most agencies discover they need much less than they assumed.