Sam Whitehead
Operations Director, The Accommodation Bureau
Last weekend, I walked into a shop and Christmas was everywhere. In the middle of September. This annoys me every year, so it really should not be a surprise anymore. But it made me realise how close we are to the end of the year. Another year that has zoomed by. This is normally the time of year when I start reflecting. It brought me back to one seriously uncomfortable realisation I had in July: “Oh jeez. What have I done?”
Within around six months at The Accommodation Bureau, we had introduced Goodlord, Tapi and MarketRent and were just about to launch LightWork AI. Each was a great product, addressed a genuine problem, and had a good team behind it. Individually, every decision was positive. Together, they represented a huge amount of change in six months. Had I tried to do too much, too quickly, and too soon?
Four good decisions became one big change
An important part of my role is to improve the business and our customer
experience. I enjoy finding the frustrations in how we work and asking whether there is a better way. I hate asking, “Why do we do it this way?” and being told, “Because we’ve always done it that way.”
I also get a genuine rush of enthusiasm from a good software demo. I can quickly see the potential: less duplication, greater consistency or time saved for our team and ideally all three. That instinct is one of my strengths. This year, I realised it can also be one of my weaknesses.
I assessed each product on the problem it would solve and the work involved in implementing it. What I did not properly consider was the cumulative effect of introducing several Proptech platforms so close together. Every implementation was competing for the same finite resource: our team’s attention.
Normal agency life did not pause. Properties still needed managing, tenants and landlords still needed answers, maintenance issues kept arriving and the new Renters’ Rights Act still had to be navigated. Alongside that, the team was learning new software, following new processes and changing habits built over many years.
Nothing went dramatically wrong. That was why the issues took me a couple of months to spot. Instead, there was a growing mental load: several implementations at different stages, processes still being refined and people trying to turn newly learned steps into everyday habits.
Then I had an honest conversation with our administrator. She told me the whole team were feeling the weight of it. Stress levels were rising. That was on me.
This was not resistance to change. If anything, the team’s willingness to make every new system work had made the problem easier for me to miss. All four decisions could be right while the overall pace was wrong.
I was several steps ahead in my own head
By the time we introduced each platform, I had researched the problem, attended demos, asked questions, and pictured the finished process. I could see where we were going.
The rest of the team was encountering that change for the first time alongside a full working day. I think I had confused seeing the destination with being ready to arrive there. I had also assumed that because each system should save time, introducing several of them would quickly save even more. I now know that is not how change works.
Each implementation involved some short-term pain for a longer-term gain. My mistake was stacking four lots of short-term pain on top of each other. New technology usually borrows time before it gives any back. There is training, testing, and an inevitable period when the old way still feels easier because it is familiar. The return comes later, once the new process has settled.
I had allowed time to implement the software. I had not allowed enough time for people to absorb the change. That was my mistake.
Going live fooled me
It is tempting to treat implementation as a project with a finish line: sign the agreement, complete the setup, attend the training, go live, and move on to the next project. But going live is nowhere near the same as being embedded.
A system is embedded when people use it confidently, the old process has genuinely stopped, feedback has been acted on, and the expected benefits are beginning to appear. That does not happen on launch day. In my experience, it won’t even happen in the first few weeks.
Going live is the technical part. Bedding in is the human part. I had planned for the first and underestimated the second. Good changes introduced too quickly can still create a poor experience for the people expected to deliver them. That responsibility sits with me; not with the products and certainly not with our team.
The people are part of the product
Now, the new processes have had time to bed in, the verdict from the team is clear: nobody wants to go back to the way we worked before. One reason the changes remained positive was the quality of the people behind them. Maintenance is the clearest example (I realise I’m writing this for Tapi’s blog, but they haven’t asked me to say what follows).
Over the past ten years, I have attended at least three demos from a market-leading maintenance software provider. It was clearly capable, but I was never convinced it would genuinely improve the experience for our landlords, tenants, contractors, and team. So we continued managing maintenance through our CRM, relying heavily on manual input and the knowledge of our property managers.
Then I met Taylor from Tapi at the EA Masters in 2025. He just got it. It felt as though he understood the problems in my head before I had fully explained them. He spoke about the reality of property management, not just features. He was enthusiastic but also open about the product’s limitations. That honesty gave me confidence.
What followed was the best onboarding experience I have ever been part of, with Taylor, Anna and Kay understanding our business and supporting the team through the change. We have had similarly positive support elsewhere, particularly from Finn at MarketRent and Gideon and Cameron at LightWork AI. It has reinforced something important for me: knowledgeable and patient support is not an optional extra. It is a vital part of the product.
When choosing technology, agencies naturally ask what it does and what it costs. I think we need to ask a few other questions too:
- Who will guide the implementation?
- Who will train and support the team after launch, and how much training is actually included?
- Can the product adapt to our workflow?
- Are they honest about the product’s limitations?
- Do they speak in technical language, or do they speak agency?
- Will they listen to feedback and act on it?
Features may persuade a business to buy a product. The people behind it often determine whether it becomes successfully embedded.
This is the bit I’d do differently
If I were planning the year again, I would definitely still make these changes. I just would not make all of them so close together. There is no perfect timetable. Projects overlap, and some problems cannot wait. But I would now leave a deliberate period for each major system to bed in before asking the team to absorb another one.
Before moving on, I would want to know:
- Can the team use the system confidently without regular intervention?
- Has the old process actually stopped?
- Have we listened to feedback and fixed any early frustrations?
- Are the benefits we expected beginning to appear?
If the answer is no, the business probably is not ready for another significant change — even if the next idea on the roadmap is excellent.
I would ask myself one more question:
Am I starting this because the timing is right, or because I am excited by what is possible?
For me, that might be the most important question of all.
My enthusiasm helps me push improvements forward. I also need to recognise when the team needs time before I introduce the next one. Slow down, Sam!
We stopped adding and started bedding in
By late summer, it was clear that we did not need to find the next new thing. We needed to give the changes we had already made room to breathe. So that is what we continue to do. We listen to the team, identify gaps in knowledge, refine processes, and check whether each system is delivering what we hoped it would.
Pausing did not mean the projects had failed or that we had lost momentum. It was the work required to turn four implementations into lasting improvements. With AI, there will always be another tool or idea I could introduce. That does not mean my team needs it this month.
I still believe the changes we made were the right ones. I just would not make them
all so close together again. The lesson for me was not to stop looking for better ways of working. It was to leave enough space to know whether the last change had actually worked.
