Your team said yes. Then nothing happened.
Here’s the system that fixes it. You raise it in the meeting. Everyone nods. You get verbal agreement around the table. And then a month later, nothing has changed. I’ve seen it with AI adoption, timesheet compliance, ticketing processes, you name it. The team isn’t being difficult. There’s just nothing making the gap between ‘we agreed’ and ‘it’s actually happening’ visible to anyone. After 20 years running MSPs, here’s what I’ve found actually works.
Nick Clift
3/11/20263 min read


Here’s the system that fixes it.
You raise it in the meeting. Everyone nods. You get verbal agreement around the table. And then a month later, nothing has changed.
I’ve seen it with AI adoption, timesheet compliance, ticketing processes, you name it. The team isn’t being difficult. There’s just nothing making the gap between ‘we agreed’ and ‘it’s actually happening’ visible to anyone.
After 20 years running MSPs, here’s what I’ve found actually works.
Make it visible before you make it accountable
At DWM Solutions we had a timesheet compliance problem. Techs were supposed to log six billable hours a day. We talked about it in monthly meetings, weekly team meetings, one-on-ones. Still patchy.
The fix was simple. At the daily stand-up, each tech reported their billable hours from the previous day out loud. That was it. When you’re standing next to someone reporting seven hours and you’re reporting three, you feel it. Peer pressure, the healthy kind, achieved in two weeks what months of conversations couldn’t.
Build metrics that can’t be gamed
I’ll be upfront. When I was an engineer, I treated KPI systems like puzzles. If there was a way to hit the number without doing the actual work, I’d find it. That experience shapes how I design these systems now.
The answer is opposing metrics. A single metric is always gameable. Pair it with something that catches the gaming:
Measure total billable hours to drive activity
Cross-check against average time per ticket to catch padding
Track total hours per client contract to surface profitability problems early
Not everything should be public
There’s a difference between transparency that motivates and transparency that distorts behaviour. Individual ticket times are a good example. If you publish them, your sharpest techs will start arriving early to grab the easy tickets. Your Level 3 escalation engineer, who is always picking up tickets someone else spent 45 minutes on, looks like a poor performer. That’s not a people problem. It’s a system problem you created.
Make total daily hours public. Keep individual ticket times private. Hold people accountable to overall numbers when the work is genuinely comparable, and not when it isn’t.
The front-end problem most MSP owners overlook
You can’t fix accountability downstream if the front end is broken. Most MSP owners make the mistake of treating all tickets the same and throwing them into a shared pool. A service desk ticket should be a problem we know how to solve. We’re scheduling time and doing the work. If the problem is unclear or the fix is unknown, it doesn’t belong on the service desk. It goes to escalation.
If you’re already in the mess, put a senior person on triage at the front end. It sounds like overkill but the cost of that role is almost always less than the cost of mis-assigned tickets and blown-out client hours.
Turn accountability into a team sport with pods
The most powerful structural change we made at Otto IT was moving to pods. Instead of one big team covering all customers, we created groups of five to seven people, each responsible for a defined customer segment. Each pod had the full mix: Level 1, Level 2, a Level 3 escalation tech, a team leader, an account manager and a sales admin.
Comparing pod versus pod instead of individual versus individual changed everything. Techs were voluntarily staying back to help a struggling teammate, not because anyone told them to, but because the pod’s numbers were on the line. That kind of ownership is almost impossible to mandate from the top.
When we merged DWM Solutions and Milan Industries, our instinct was to mix everyone together. One big team, shared customers. In practice it fell apart fast. Customers were getting one of 15 possible technicians per call, and techs were getting tickets for technology stacks they’d never seen. Once we split into vertically segmented pods, both the customer experience and team experience improved almost immediately.
Five to seven people per pod. Once you hit seven or eight, split. Twelve technicians gives you roughly two pods of six once you account for leave cover. Manage resource conflicts between pods with a fortnightly scheduling meeting.
The thing that makes all of it work
If I had to reduce all of this to one principle, it’s transparency. Not dashboards and metrics for their own sake, but making sure every person on the team understands their role, how it connects to the roles around them, and what happens downstream when they don’t follow through.
Get that right and the stand-ups, the pods, the opposing metrics, all of it lands much more easily. Get it wrong and no amount of measurement will compensate.
If any of this sounds familiar, I’d love to hear where you’re stuck. Drop a comment below or reach out directly.
Nick Clift · Tenassia MSP Coaching · nick-clift.com
