Founder of https://nitter.gq/t.co/zTZe8CiM9o Chairman at RSVP (Media Response) Ltd
Monaco
Joined January 2009
- Tweets413
- Following17
- Followers3.8K
- Likes42
I've been in the middle of an argument between a manager and a worker over hours, and neither side had anything to prove their version of events.
Both of them were certain they were right.
The manager's records were partial, reconstructed from memory at the end of a long week.
The worker's recollection was clear and specific, as people's recollections tend to be when money is involved.
There was no record to settle it.
The outcome was managed rather than resolved, which is a different thing: someone walked away satisfied enough, and the actual question of what happened on that particular day was never answered cleanly.
I've been in that situation more than once across different businesses, and the pattern is always the same.
The argument isn't really about honesty.
It's about the absence of information that both sides assumed existed somewhere.
Team-Trak was built from those moments.
Not from a whiteboard exercise about what a workforce management product should do, but from the specific situations where not having a verified record made something harder than it needed to be.
A timesheet and a verified attendance record aren't the same thing.
A timesheet tells you what someone reported.
A verified attendance record tells you what happened: who was where, confirmed by GPS at the moment they checked in, with a timestamp that exists because the system created it rather than because someone filled it in.
The distinction doesn't matter on a normal week when everything goes as expected.
It matters when hours are disputed, when a client questions whether a job was covered, or when a manager needs to know exactly what happened on a specific day.
One of those situations is a memory exercise.
The other has a verifiable answer.
When a feature request comes in, I don't build it immediately.
I sit with whether it's solving a problem the customer actually has or a problem they think they have.
The QR code is the clearest example I can give of getting that right.
My instinct when building Team-Trak was that GPS verification was enough.
You're within the boundary of the job site, you check in, and the system logs it.
Simple, accurate, nothing extra required.
Then clients started asking for the QR code option.
Not all of them, but enough, and the reason they kept giving was consistent: GPS felt invisible.
They wanted something physical, something the worker did at the specific location, something they could point to as confirmation.
I listened, we built it, and a transport client put a 2-foot version on the wall of their depot.
That feature now comes up regularly in conversations with new clients as something they specifically value.
If I'd dismissed the request because GPS technically solved the same problem, I'd have built something accurate that people didn't fully trust.
Accuracy and trust are 2 different requirements, and a product that meets only one of them has a gap in it.
If the only time you find out something went wrong with your mobile team is when a client calls to tell you, you're not managing the problem.
You're receiving the report of it after the relationship has already taken a hit.
By that point, the question isn't what happened.
It's how to explain it to someone who's already formed a view.
The businesses that catch operational problems early are the ones with a system that surfaces them before anyone else does.
The ones that find out from clients first are the ones where the information flow runs in the wrong direction.
Most people assume that decades of experience running businesses translate directly into knowing how to build a product.
The operational instincts transfer.
The customer empathy transfers.
The ability to identify a real problem and stay close to whether you're solving it transfers.
What doesn't transfer automatically is everything specific to the medium.
SaaS has its own feedback loops, its own relationship with users, its own definition of what onboarding means and what retention requires.
I came in knowing the problem well and the medium barely at all.
That combination has been more useful than I expected and more humbling than I anticipated.
I worked in the electricity industry years ago, and the time-keeping situation there was something I'll never forget.
The workers had covered every angle.
Early arrivals clocked in the whole crew before anyone else had arrived.
They had creative interpretations of break times.
A general fluency with the gaps in whatever system the business put in place, applied consistently and without much guilt, because the system felt arbitrary and the workarounds had become normal.
I spent a lot of time as a young apprentice being frustrated by it.
Looking back, I was frustrated at the wrong thing.
The workers hadn't invented those behaviours.
The system had made them available, and people will generally find the path of least resistance when the cost of doing so is low and the consequences are unclear.
What changed my thinking wasn't a crackdown or a new policy.
It was the gradual realisation that a system designed to be gamed will be gamed, and that the answer isn't to make the rules stricter.
It's to build something where the shortcut simply isn't there to take.
That shift in how I thought about workforce systems stayed with me through every business I built after that, and it's the foundation of how Team-Trak approaches verification.
The first significant thing Team-Trak taught me about SaaS was that silence isn't satisfaction.
In a service business, when something isn't working for a customer, you usually hear about it.
A call, a complaint, or a conversation that tells you something needs to change.
SaaS introduced me to a different pattern.
Users who signed up, hit a friction point in onboarding, and simply stopped, without explanation, without a complaint, without any signal that would have told me something was wrong if I hadn't been watching the data closely enough.
300 signups.
A broken email sequence.
Users dropping off before they'd seen what the product could do.
That gap between someone finding your product and someone actually using it is the thing I'd most underestimated coming in.
The blue-collar service sector has been underserved by technology for decades.
Not because the problems are hard to solve.
Because the businesses are too small to attract serious investment in purpose-built tools, and too busy to spend time evaluating what's available.
So they absorb the manual admin, normalise the inefficiencies, and get on with it.
The enterprise software companies built products for organisations with IT departments and implementation budgets.
The workaround economy, text threads, shared spreadsheets, and clipboards in trucks filled the gap left behind.
A cleaning business with 12 employees or a construction outfit running 8 subcontractors has exactly the same workforce visibility problem as a larger operation.
They just had far fewer options built specifically for them.
A client calls to say the cleaner didn't show up this morning.
The business owner checks the text thread.
There's a message from the worker at 8:45 saying she's on her way, but nothing after that.
The owner calls the worker.
She's certain she was there, completed the job, and left at 11.
The client is equally certain nobody came.
No record exists to settle it.
The owner now has to manage a client relationship, a worker relationship, and a dispute they have no way of resolving cleanly, all before lunch.
They'll handle it, because they always do.
But one of the two people in that dispute will walk away feeling like the outcome wasn't fair, and a client who's had that experience once starts to wonder whether it might happen again.
That specific scenario is one of the things Team-Trak was built to prevent.
Not by catching anyone out, but by making the record automatic so the conversation never has to start from a place where nobody has any information.
The blue-collar service sector has been underserved by technology for decades.
Not because the problems are hard to solve.
Because the businesses are too small to attract serious investment in purpose-built tools, and too busy to spend time evaluating what's available.
So they absorb the manual admin, normalise the inefficiencies, and get on with it.
The enterprise software companies built products for organisations with IT departments and implementation budgets.
The workaround economy, text threads, shared spreadsheets, and clipboards in trucks filled the gap left behind.
A cleaning business with 12 employees or a construction outfit running 8 subcontractors has exactly the same workforce visibility problem as a larger operation.
They just had far fewer options built specifically for them.
If your business runs well when you're handling everything personally but starts to strain the moment you step back, the system holding it together is you.
That's a workable arrangement up to a point.
The point it stops working is usually when you want to grow, take on more work, or step away for any length of time without things requiring your constant input.
The businesses that scale past that point are usually the ones that replaced personal oversight with consistent processes before growth made it urgent.
The ones that wait tend to find out they needed those processes at exactly the moment they're least able to build them.
Every major product decision I've made on Team-Trak has been made without a full understanding of the space I was building in.
Not because I was careless about it, but because that's the situation.
You're building something that doesn't exist yet, in a category you're still learning, and the decisions don't wait for you to become an expert first.
What I've found is that expertise in the problem is different from expertise in the solution, and confusing the two is where a lot of founders get stuck.
I know the problem intimately.
I've lived on the wrong side of it across cleaning businesses, call centres, transport operations, and construction.
What I didn't know when I started was how to build the software that solved it.
So I found the right people, asked the right questions, and made judgment calls on the things that required a decision before the answers were fully available.
That's not a gap in the process.
That's the process.
Waiting until you understand everything before you build anything produces very thorough analysis and very few products.
The judgment you develop over a long career isn't about knowing the answer in advance.
It's about being able to make a reasonable call with the information you have, stay close enough to see what happens, and adjust from there.
3 questions Team-Trak answers in seconds that used to require a phone call.
1 - Is everyone on site right now?
A manager can check the app and see a live record of who has checked in, where, and when, without contacting anyone.
2 - What time did that job actually start?
The check-in record is timestamped and GPS-verified. No need to ask the worker or reconstruct it from a text thread.
3 - Did anyone check in from the wrong location this week?
Anomalies flag automatically. The manager sees them without having to go looking.
The calls themselves aren't the problem.
It's the cumulative cost of running a mobile team through a series of individual conversations that each take a few minutes and together take a significant portion of every working day.
It’s at the end of the week when the timesheets are created, payslips and invoices are available that the benefits really shine through.
I came into software the same way I've come into every industry I've built in: knowing the problem well and the landscape barely at all.
That's been the pattern across 50 years of building service businesses in sectors I had no prior background in.
The learning curve was familiar.
What wasn't familiar was how different the feedback loops are in SaaS compared to anything I'd operated before.
In a service business, when something isn't working, you usually find out quickly and personally.
A client calls, a manager flags it, and someone on the team tells you before it becomes a serious problem.
SaaS introduced me to a different kind of silence.
Users who signed up for Team-Trak and didn't progress through onboarding didn't call to explain themselves.
They just stopped.
And if you weren't watching the right signals closely, the absence of noise felt like everything was fine.
That specific gap between how a service business and a SaaS product relate to their users was the sharpest thing the early months of Team-Trak taught me.
The product knowledge transferred well enough.
The operational assumptions that came with it were a different matter.
Now we follow up and can discover if there is something we’ve overlooked or made to difficult. We continue to improve the product based on feedback.
Many small service businesses are running their attendance on a WhatsApp thread and treating it as a system.
A text thread is a communication tool.
It wasn't designed to hold attendance records, and the difference between those 2 things only becomes visible when something goes wrong, and you need to find a specific exchange from 3 weeks ago, produce a verified record for a dispute, or explain to a client exactly what happened on a particular day.
The businesses that make the switch to a proper attendance system usually can't believe how long they managed without one.
The thread didn't feel like a problem until they saw what they'd been missing.