When a founder can't see their team working, the first thing they reach for is usually a way to see them working: screenshot tools, activity percentages, "active time" dashboards. It feels like measurement.
It isn't. Those tools measure whether a mouse moved. A developer thinking through a hard bug for 40 minutes looks idle. Someone clicking between tabs looks busy. And within a month your team knows exactly what the tool counts and gives it what it wants.
The question you actually have is simpler: is the work getting done, at the pace and quality I'm paying for? That can be measured without watching anyone.
Measure output, then measure reliability
For a small service business, productivity comes down to two things:
- Output: how much finished work comes out, of acceptable quality.
- Reliability: whether people deliver what they said they would, when they said they would.
Most founders actually care more about the second. A person who reliably delivers what they commit to is easy to plan around even if they're not the fastest. A brilliant person who misses half their commitments breaks every plan they touch.
Five measures that work for small teams
You don't need all five. Pick two or three that fit how your team works.
1. Planned versus delivered
At the start of the week (or the day), each person names what they'll finish. At the end, compare. Over four weeks:
| Person | Planned items | Delivered | Hit rate |
|---|---|---|---|
| Amira | 38 | 34 | 89% |
| Jonas | 41 | 26 | 63% |
| Priya | 30 | 28 | 93% |
Jonas planning more and delivering less isn't automatically a problem. It might mean he's being interrupted, over-committing, or handed vague tasks. But it's a specific, fair thing to talk about, which "you don't seem busy" is not.
2. Estimate accuracy
If people estimate tasks and log time, compare the two. A team that estimates 4 hours and takes 9 isn't necessarily slow; the estimates may be wrong. Either way, you want to know, because your quotes depend on it.
Estimate accuracy = estimated hours ÷ actual hours
Track it per person and per type of work. You'll often find one category (say, QA, or revisions) that everyone underestimates by 50%. That's a pricing fix, not a people fix. This connects directly to utilization, which tells you whether logged hours are going to paid work at all.
3. Cycle time
How long a task takes from "started" to "done". Not effort hours, but elapsed days. Long cycle times usually mean waiting: for reviews, for client feedback, for answers from you. That's the most common hidden drag in small teams, and it's rarely the person's fault.
4. Rework
How often finished work comes back. Bugs reopened, designs sent back for reasons that should have been caught, deliverables the client rejects. A person with high output and high rework isn't productive; they're moving work onto someone else's plate.
5. Client-facing timeliness
For client work: did deliverables reach the client by the date promised? This is the measure clients actually judge you on, so it's the one to share with the team.
A worked monthly scorecard
Here's what a one-page scorecard looks like for one person, using three of the measures. Keep it this simple.
| Measure | This month | Last month | Note |
|---|---|---|---|
| Planned vs delivered | 84% | 71% | Fewer interruptions after support rota |
| Estimate accuracy | 0.78 | 0.74 | Still underestimating QA |
| Deliverables on time to client | 9 of 10 | 7 of 9 | One late: waiting on client assets |
Look at the notes column. Every number gets a reason next to it, and the reasons are where the useful conversation is. A scorecard without notes turns into a league table.
Where the data comes from
You need two sources, and both are probably things you should have anyway.
Tickets with estimates and logged time. If work lives in a project tool and people log time against tasks, you have planned work, estimates, actuals and cycle time. In Suprwork, Projects & Time compares estimates with the hours actually logged, person by person, and shows workload across the team.
A daily plan and check-out. A short note each morning of what someone plans to do and a note at the end of what got done gives you planned-versus-delivered without any extra admin. If you'd rather not build this in a spreadsheet, Check-ins does this and gives you a daily written summary with blockers called out.
Neither of these watches anyone. They record what people say they'll do and what they did, which is the information you need to manage.
What not to measure
Hours online. Measures presence, not work. It also punishes your fastest people, who finish early.
Messages sent or tickets touched. Easy to inflate. Someone moving a ticket back and forth four times looks very active.
Lines of code, number of designs. Rewards volume over value. The best solution is often the smaller one.
Anything you'd be uncomfortable showing the person. If you wouldn't put the metric in front of them in a 1:1, you shouldn't be collecting it.
Using the numbers without wrecking trust
Measurement only helps if people believe it's fair. A few rules:
- Same measures for everyone, including you if you do delivery work.
- Trends over weeks, never single days. Everyone has a bad Tuesday.
- Discuss in private, in 1:1s. Never post individual rankings.
- Ask before you conclude. A drop in hit rate is a question: what changed? Often the answer is something you caused, like a new client or an urgent pitch.
- Use it in reviews as evidence, not verdicts. Numbers plus the person's own account make a fairer review than either alone.
Team-level measures come first
Before you look at any individual, look at the team as a whole. Most productivity problems in small service businesses are system problems that show up in everyone's numbers at once:
| Team pattern | Likely cause |
|---|---|
| Everyone's planned-vs-delivered drops the same month | A new client, a pitch, or too many meetings |
| Cycle time rising across the board | Reviews or client feedback are the bottleneck |
| One type of work always over estimate | The estimate is wrong, not the people |
| Rework concentrated on one project | Unclear brief or a client changing direction |
If the whole team slows down at once, look at what changed around them, not at any one person. Fix the system first. Individual measures only become meaningful once the shared causes are out of the way, and you'll find most of the "productivity problem" disappears when they are.
When the numbers point to a person
Sometimes, after all the context, one person really is delivering much less than the rest. The measures above help here too, because they let you have a specific conversation:
Over the last six weeks you've delivered about 60% of what you planned, and the rest of the team is above 85%. I want to understand what's getting in the way.
That's a conversation someone can respond to. "I don't feel like you're pulling your weight" isn't. If things don't improve after a genuine fix, you have a documented, fair basis for a performance plan.
This week
Start with one measure: planned versus delivered. Ask each person to write three things they'll finish this week on Monday, and check them on Friday. Do it for four weeks before drawing any conclusions. By the end you'll know more about your team's real output than any activity tracker could tell you.