 |
In this post I am going to explore "What the Social Housing Front Line Really Thinks About Repairs Tech". So, strap in !
If you’ve followed this blog for a while, you’ll know I spend a lot of time deep in the weeds of housing ICT – particularly procuring & implementing contractor repairs systems, DLO set‑ups, CRM that costs a fortune and still manages to annoy residents and staff in equal measure (and the rest!).
So when I read “Middle Ground” by Joe Carpenter – a book written by someone who’s actually been out there on the tools doing 14,000+ repairs – it hit a nerve. I read it almost in just 3 sittings, (rare for me these days as I am so busy). A lot of what Joe describes is exactly what I see when I sit in contact centres, ride along in vans or are engaged to untangle the mess left by badly implemented systems. Forgive me, this is a bit of a longer read than usual, but I promise you very insightful and rewarding.
I asked Joe if he’d be up for a straight‑talking Q&A about repairs, mobile working/field service, CRM, damp and mould, and all the stuff that never quite makes it onto the glossy supplier slide decks. He very kindly like the other legendary man from Del Monte, said yes. What follows is a condensed version of that conversation – the good, the bad and the very familiar, which IMHO holds an essential mirror up to the sector as a whole.
“CRM won’t fix a relationship you don’t have”
I grew up in council housing well east of Manchester when you still had local offices, fortnightly rent collectors (the ultimate data profilers) and staff who actually knew the estates Finnigan gas & Wimpy electric heating sides. Now we’ve got more of the big centralised call centres and expensive CRM systems, that often are supposed to make things better. Why do providers keep getting CRM so wrong?
Joe’s view is blunt: "Too many landlords treat technology as a replacement for human connection instead of something that supports it". In the past, housing offices were based on the estates. Tenants could walk in and talk to someone they knew. Staff saw the blocks, the streets and the people every day, so trust and understanding was built naturally.
Now most services sit behind screens, tablets and workflows. That centralisation and distance makes it far too easy to lose sight of the people you’re meant to be serving. Even the best CRM can’t fix that on its own. If staff never see or speak to residents, the system is just logging interactions, not building relationships.
In Middle Ground, Joe does argue for better digital tools – but only once the basics are in place: more localised services, better communication and real connection with tenants. Tech should enhance relationships that already exist, not try to paper over the cracks when they don’t.
Where repairs go wrong – before the van door opens
I’ve spent years helping landlords pick call‑scripting tools to improve repair scripting & issue diagnosis. Joe you describe loads of bad call logging in the book. What did that look like in real life?
Joe points to one simple, very common example: anything labelled as a “vent”. With call‑handlers under pressure to get through calls quickly, job descriptions ended up vague and misleading. Strange how salesfolk often walk through a "leaking tap issue". They would never tackle a vent!
He saw cases where a glazier was sent to an electric extractor fan, an electrician sent to a trickle vent, a multi‑trade sent to the wrong type of vent entirely, or a glazier dispatched for what turned out to be a wall vent. Everything was just logged as “vent broken”.
Because the system wasn’t doing anything like capturing the right detail consistently at the start, often the wrong trade turned up, the job bounced between teams and the tenant waited longer (or forever). From Joe’s perspective, “the repair is already going wrong before anyone steps out of the van”, if the diagnosis and coding at the front end aren’t right.
Mobile working: tool or surveillance?
Joe, I am sure many of you have used a few of the mobile and job‑management systems I come across in my work. Do you think getting operatives and frontline staff involved much earlier in the procurement journey would actually improve outcomes?
Joe’s answer is an immediate “Yes”. The people using these systems every day know exactly where the pain is. They see the extra clicks, the slow and often unreliable interface syncing, the random crashes and the bits that simply don’t work on a damp block landing with no signal.
Too often, new systems feel like they’ve been designed to more monitor and control operatives, not to help them. That’s usually because no one asked the people doing the work what they actually needed.
In Joe’s view, “if you involve a proper mix of users – operatives, planners, supervisors and call‑centre staff – from the start, you’re far more likely to end up with something that supports the job instead of getting in the way. Then it becomes a tool people want to use, not something they’re forced to tolerate”.
Get out in the van
I’ve always made a point of going out in the van with DLO operatives to see how systems work in real life or at the very least spending quality time with trades. Joe, is that something you think organisations should do more of?
Joe thinks it’s essential. “When staff from other parts of the organisation ride along in the van or shadow frontline workers, they see the homes, the conditions and the practical obstacles first hand. That changes how they think about policies, processes and systems.
It also builds empathy. It’s harder to sit in an office designing clunky workflows or unrealistic KPIs once you’ve watched someone try to get three emergency jobs and a safeguarding concern dealt with before lunchtime”.
When “proof of concept” isn’t proof of anything
You mention a new mobile system being trialed on voids before being rolled out to reactive repairs. What went wrong there?
In Joe’s example, he and a colleague trialed a system on voids work for two weeks. “But voids and day‑to‑day repairs are completely different beasts. On that trial, they only worked on one sheltered scheme refurbishment.
Reactive repairs are about handling many jobs per day. Voids work is fewer, bigger jobs. Basing the success of a whole mobile system on that voids pilot was, in his words, a mistake.
Some bits worked – uploading photos, writing descriptions – but key elements like van stock and replenishment didn’t really get tested. When the system later went live for reactive repairs, those gaps became real problems”. As far as Joe knows, there was no proper operative testing (UAT) in a live reactive environment before go‑live, and that showed. So, a clear lesson to be learned right there. Voids for sure is "Gang Working", similar to planned work. On many occasions I have recommended taking those operatives out of scheduling OR managing it in a different more practical fashion.
Scheduling: one job at a time vs a full diary
Dynamic scheduling tools are a constant source of complaints. Joe you write about how you preferred seeing your whole day’s work. Would that approach suit most operatives?
Joe says “he’s never met an operative who genuinely prefers being drip‑fed one job at a time. People want to see the full diary. It helps them plan, prioritise and stay motivated”.
Joe understands why managers like the flexibility of allocating work job‑by‑job – it makes it easier to reshuffle when there’s no access or someone finishes early. But from the front line, hiding the rest of the day’s work just makes life harder.
A practical suggestion he made, which actually got implemented, was a live list of communal jobs for each patch. If an operative finished early, they could check that list, pick something nearby and get it done, instead of waiting on planners who were already stretched. A simple change, but it reduced downtime and faffing about at the end of the day.
Stock, vans and the blame game
Van stock and materials management are painful in nearly every DLO I see. How did that play out for you?
When Joe worked independently, he had the freedom to buy from whichever stock supplier was quickest and most cost‑effective, and to build up his own van stock based on what he knew he needed for his patches.
"Back in the DLO, everything went through a main contracted supplier. For specialist items, that supplier went elsewhere and added admin costs on top, which meant delays and extra expense.
There was a van stock system built into the contractor system, tied to each job. In theory, you logged materials used on your PDA before closing the job. In practice, Joe found that after trying to use it properly, items kept going missing from his van stock records. He gave up and resorted to writing job numbers, addresses and parts on paper, then spending unscheduled time at the supplier’s picking everything up one job at a time.
When he tried to get it fixed, the supplier blamed the contractor system, and IT blamed the supplier. The usual integration circle, often in my experience only solved with a 3 or 4 way lock-in"
Planned vs reactive budgets & spend – talking to each other? Not really
In the book you talk about kitchens being partially replaced on repairs, then fully replaced soon after on planned programmes. Is that kind of disconnect between planned and reactive as common as it sounds?
Short answer from Joe: “Yes. He describes repeatedly contacting planners to check if there were any upcoming planned works, and either they couldn’t find anything on the system, or they had to wait on someone else to get back to them”.
That lack of joined‑up information means money gets wasted and residents get disrupted twice or worse, for work that could have been coordinated once.
Angry before you’ve even knocked on the door
Joe you describe residents being angry and disappointed before you even start the repair. With modern systems, it should be easy to share priorities and target dates. Was that information reaching residents in any meaningful way?
Joe met plenty of residents who were already frustrated before he arrived. The most common complaint and I have seen this too, first hand: “They’d been waiting far too long. That frustration got worse when he turned up without the right parts because the van stock process had failed, or when his diary was so packed he couldn’t spend enough time on the job and it had to be re-booked”.
He also saw jobs mis‑categorised. Insecure windows and doors – where a tenant couldn’t secure their home – were logged as routine rather than emergency, a diagnosis question rarely asked. Residents resorted to ropes, sticks and makeshift solutions while they waited. Meanwhile, some routine jobs were mistakenly treated as emergencies, dragging resources away from cases that really were urgent.
Damp, mould, Awaabs Law and blaming “lifestyle”
Post‑Awaab, I’m spending a lot of time talking to landlords about damp and mould ICT & processes. In your experience, how much of it is structural versus so‑called lifestyle?
From Joe’s experience, “The majority of damp and mould cases he attended were driven by the fabric and condition of the building, not resident behaviour. He points to poor insulation and cold bridging, inadequate ventilation or poorly maintained extractors, leaks from roofs and gutters, and windows and doors well past their replacement date.
Older stock simply wasn’t built for modern energy demands, and many residents can’t afford to heat their homes properly. Even when they follow advice, the property still works against them”.
He argues that preventative maintenance – regular checks of roofs, gutters, ventilation and seals – should be standard. Better use of data is critical too: if operatives are dealing with damp repeatedly in the same locations, that should trigger capital investment, not another short‑term clean and paint. Stock condition surveys need to drive action, not just sit in a system somewhere. And yes, resident education has its place, but only alongside proper investment in the homes themselves.
Safeguarding – why Joe didn’t trust the system
You mention adult safeguarding and other serious concerns spotted while doing repairs. Did the systems you used help you report those issues properly?
“There was a safeguarding team, but they sat in a different part of the organisation. Joe believes there may have been a safeguarding form somewhere in the mobile system – the same platform also did things like uniform orders and vehicle checks – but the system was so unreliable that he didn’t trust it.
Simple requests, like ordering a T‑shirt, weren’t reliably reaching the right person, so he wasn’t prepared to risk a safeguarding concern getting lost in the same way. Instead, he phoned safeguarding issues through directly. Even then, he wasn’t always confident they’d be acted on, but at least he’d spoken to a human being. The conclusion is clear: if operatives can’t trust the system for basics, they won’t trust it for critical issues either”.
Right to Buy – selling off the safety net
You rightly call out Right to Buy as one of the big reasons we’ve lost so many genuinely affordable social rented homes. Scotland and Wales have scrapped it. Why do you think England still clings on?
Joe sees it largely as politics and I would be inclined to agree. ”Right to Buy is still treated as a vote‑winner in England – a symbol of aspiration and independence. Governments like being able to promise home ownership, and a lot of people who’ve benefited from RTB are a significant part of the electorate”.
The problem, he points out and its difficult to disagree with, is that it’s never worked as intended. Homes sold haven’t been replaced like‑for‑like, and plenty of ex‑council properties now sit in the private rented sector at much higher rents and also often in way worse condition.
With demand rising and social stock shrinking, he doesn’t see the current model as sustainable. Ending RTB, or at least reforming it so every sale actually funds a replacement in the same community, would be a start.
What the DLO really wants from your “fancy” systems
This is the most interesting part of our chat. Joe you’ve worked inside a DLO and now written about it. If you could design the perfect operative workflow, what would it actually look like?
Joe’s ideal model is simple but not cheap: “Keep repairs and maintenance in‑house, managed locally in small, well‑defined patches. Operatives, caretakers, cleaners and housing officers all work the same area, know the stock and know the people.
Tenants should be able to report repairs easily – via an app, a phone call or by walking into a local office where they see familiar faces. Contact centre staff would be aligned to those local patches too, so they understand common problems and local context.
On the tech side, he wants a system that gives operatives full visibility of their work in real time: all the day’s and week’s jobs on their device, with clear details, photos, tenant notes, access requirements, asbestos info and history. If you’re already at 3 Station Road and there’s another job at 6 Station Road later in the week, the system should make it easy to pick that up while you’re there”.
“Real‑time van stock integration is key, ideally with an in‑house store to keep costs under control. Raising follow‑on work should be quick and simple, not a war with drop‑downs and obscure codes. Notes, photos and signatures should upload reliably without the system freezing.
When the job is done, the status should update instantly for planners and residents, avoiding unnecessary calls and delays. In short, Joe wants tech that helps operatives fix things first time, not systems that make the job harder”.
And what about AI?
Everyone’s shouting or worried about AI at the moment. Where do you genuinely see it helping repairs, if at all?
Joe sees potential, but only if it’s aimed at real problems. “For diagnostics, AI could analyse resident reports, photos and property history so operatives arrive with the right parts and skills, instead of gambling on vague codes and half‑finished job notes”.
He also sees a role in safeguarding – spotting patterns like repeated no‑access, hazardous living conditions in photos or behaviours that suggest vulnerability, and reliably flagging these to the right team.
“On site, AI could provide real‑time support: pulling up manufacturer instructions, checking parts availability or helping an operative talk through an unexpected issue without multiple visits. And if voice and image recognition can take away some of the admin – logging notes, materials and compliance documents accurately in the background – that would free operatives to focus on the repair instead of fighting the system.
Used well, AI could also help predict failures and spot patterns in the stock, preventing breakdowns before they happen”. But as Joe would say, it needs to solve real problems, not just create flashy new ones. I am aware that many areas where maybe AI could be targeted, in reality we are barely utilising many existing features well.
Final thoughts
Talking to Joe just reinforces what many of us already know: a lot of what’s going wrong in the repairs service isn’t about a lack of systems. If anything, there are too many. The real gaps are in design, trust, culture, local knowledge and basic follow‑through.
If RSL’s, RP’s, AHB’s and council providers want different outcomes – fewer angry residents, fewer repeat visits, fewer damp and mould headlines, better use of budgets – they’ll need to start listening to people like Joe properly, build tech around real workflows and stop pretending that another magic rebrand or quickly dropped in CRM module, will magically fix years of structural issues.
Joe also has an excellent Substack, check him out at Behind The Tools.
While this is a pretty condensed version of my chat with Joe, I am sure I will come back and explore some more areas discussed in detail, in the coming months.
Related Post: Webchat - is it really worth bothering ?
I would be pleased to connect with you on LinkedIn - http://uk.linkedin.com/in/tonysmiththathousingitguy Message
me with any issues or queries, you would like to be explored in this
blog. We generally receive a couple of suggestions each month.
Birdland - Middle Ground
(c) Tony Smith, Acutance Consulting www.acutanceconsulting.co.uk 07854-655009
Access a quick list of our Social Housing ICT blog posts here , what projects do we get involved in? Access them here
Could we help you or your organisation? Our contact details are here , get in touch we will be pleased to chat about your problems and help with your organisation issues.
File
Under:
#HomesForBritain,#HousingDAY,#InternetOfTenants,#Shout,#UKHousing,
07854655009, 1st Touch,1stTouch,360,365Agile,3squared,4Js,
ACL,ALMO,AMS,AX,Aareon,Abritas,Academy,Accuserv,Accuserve,Active
Housing,ActiveH,ActiveF,ActiveFinance,ActiveHousing,Acutence,Advanced,Affinity,Aidenn,Agile,Agile365,AHB,AirWatch,Alscient,Alfresco,Alignment,Allpay,Amazon
Web Services,Anite,Apex,App,ArchHouse,Archouse,Asprey e-state pro,Asset
Management,Associates,Aurora,Average IT Costs,AWI SX Integration
Toolkit,AWS,
BI,BO,BPR,BancTec,BigChange,Blockwise,BluTek,Bluebox,Blueprint,BrikHousing,Browser
Applications,BC, Business Central, Business Objects,Business
Planning,Business Process Review,Business social networking, CACI,Capita
One Housing,CBL,CCS IT Keystone
CCSIT,CEDRM,CHICS,CHR,CIH,CMS,COA,CORE,CPL,CRM,CRM2013,CRS,CTI,CTX,Cadcorp,Capita,CapitaOne,Capita
One,Capital Management,Cashflow,Castle,Castleton,Castleton
Technology,Cedar Open Accounts,Cerrus,Change,Charges,Chartered Institute
Of Housing,Cheaper Housing IT,Chics, Citrix,Civica,Civica CTX,Civica
Cx,Civica Genero,Civica Saffron,Clearview,Clik,Cx Assets, Cloud
Dialogs,CloudDialogs,Coactiva,Codeman,Comino,Commontime,Community Reward
Services,Company,Competitive Dialogue process,Component
Accounting,Consilium,Consolidation,
Consultancy,Consultant,Consultants,Contact Manager,Context,Contractor
Systems,CorVu,Cost Reductions,Covalent,Crystal Reports,Customer
Relationship Management,Cx,CxFeedback, DRS,Deeplake,Designer
Software,Development
Systems,Director,Document,Documotive,Docuware,Dynamic
AI,DynamicAI,Dynamics 365,D365,Dynamics365,Dynaway
ECMK,EDM,EDRMS,ERP,ESRI,Elmhurst,Enghouse
Interactive,England,English,EnterpriseBI,Estatecraft,Esuasive,Esynergy,Etive,Exhibition,Exponential-e,
F&O, Facebook,Factorwise,Field Service management,Finance,Financial
Systems,Financials,FLS,Footprint,Forms,Freezes,Fusion,Fuzzlab Gas
Tag,G-Cloud,GCloud,GDPR,GGP,GIS,GasTag,Genero,GeoSolveIT,Getting best
from,GoTonySmith,Grasp,Grip,Group Apex, HCL,HFI (Housing Financials
interface),HG,HRA,Hardware,Hitachi
Systems,Hitex,HomeMaster,Hometeam,HouSys,House,Housemark,Housemark
survey,Housing,Housing Contact,Housing Group,Housing Insight,Housing
Management,Housing Management Consultant,Housing Partners,Housing
Portfolio Management System,Hub Asset Management,Homeswapper,Housing
jigsaw,HousingOne,Housing-One, Housing Support
Pro,HousingIT,HousingSupportPro,HyperOptic, IMS,IPC,iProperty
Cloud,IT,IT Budget,IT Training,ITIL,Impact Response,In,In4,In4Systems
Promaster,InfinityGroup,InfoBoss,InHouse,InMotion,InMotion2015,InMotion2016,InfoBoss,Infoflow,Information,Information
Technology,Information@Work components,Informix,Innovation,
Informetis,Inphase,Inside Housing,Insight,Internet
Portal,Internetalia,Invu,Ireland,Irish,itLab,InclineIT,
Keyfax,Keylogic,Keypera,Keystone,Kirona,Kypera,Keynamics,
Landlord,Ledgers,Linkedin,Liquid,Locality,Localz,
M3,MadeTech,MAVIS,MD,MDM,MI,MIS,MIS-AMS,MISCS,MRI,MS Dynamics,MRI,MS
Dynamics CRM2011,Microsoft365,microsoft 365,MWL,Management,Management
Server,Manifest,Measuring,Mebus,More IQ,MoreIQ,Microsoft Dynamics
365,Microsoft dynamics GP 2013,Miracle,MobileIron,Mobysoft,Monopoly
board images and pictures,Montal,Mr Void,MriEngage,MrVoid,MoreIQ,
MRI,MRI Housing One, NDL,NINTEX,NINTEX workflow,NPS,NPS ASSIST,NPS
Housing,NPS Job Manager Mobile,NROSH,Natural,Neighbourhoods and
Communities,Nintexworkflow,Northgate,Northgate Codeman,Northgate Public
Services,Notice, OA,OGC Buying Solutions,OJEU
Limits,ORS,Ohms,OmFax,Omniledger,One,OneAdvanced,OneServe,Open
source,OpenContractor,OpenHousing,Opti-time,Options,Optitime,Oracle,Orchard,Outsource
and outsourcing,OutSystems, PIMMS,PIMSS
Data,PM,PRINCE2,Paloma,Pamwin,PanConnect,People
Value,Peoplevalue,PfH,Pick,PlanForm,Planned
maintenance,Plentific,Plus,Portfolio Management
System,PowerObjects,Pro,Pro-Points,Prodo,Progress,Promaster,Propeller,Propoints,Proval,Providers,Pyramid,
QL,QLX, QLF, QL Yuneo,QuantSpark,Qube,QLX,Qlikview,QueryView,Queryview
reporting,Quiss, RM865,ROCC,RPs,RSL,Rave,ReAct,Reality,RedkiteCRM,Red
Olive,Registered,Registered Social,Rent
Increase,RentSense,RentSenseLite,Repairfinder,Reporting,Reports,RobotAutomation,Rocket,Rubixx,
Salesforce,Salesforce.Org,SAP,SASSHA,SDM,SHBVN,SM,SOTI,SP,SQL,SQL Open
Housing,SQL Reporting,SQL
Server,Saffron,Safron,Saturn,Scenario,Scotland,Scots,Scottish,Scout,Sequoa,Serengeti,Serros,Server,Service,Services,Servitor,Sharepoint,Sim,SimPro,
Simdel,Simdell,Slash and Burn,Social Housing ICT,Social Housing
Software Applications,Social Media,Software,Software solutions,Spotlight
Service,Spotlightservice,Star rating,Stores and
Stock,Strategic,SunAccounts,Sunguard,Surveys,Streetwise,
Swordfish,Sx3,Symatrix Human,System alignment,Systems,Systemwise,
T-Files,TEAMS,TED,TFiles,TP Tracker,TSG,Tagish
Casework,Tagra,Task,TAIM,Techlabs,Technologies (India) PVT
Limited,Telecetera,Template,Terminal Services,That,Three
Star,Tilt,TiltAffinity,Today,Tony Smith,Tony Smith That Housing IT
Guy,TonySmith that housing IT,TonySmithHou,TonySmithHousing,
,TonySmithHousingITguy,Total,Total
Mobile,Totalmobile,Trace,Tribal,Twitter, U2,UC,UK,UK
Housing,Ukhousing,UniClass Enterprise,Unidata,United
Kingdom,Universal,Universalcredit,Universe,Unrest, Valueworks,Van
Stock,Vantage,Vantage
Sentinel,Version,Virtualisation,Visitour,Visualmetrics,Voice,Voice and
data,Voicescape,Voluntas, Wales,Welsh,Wheatley,Windows Server,Workflow
and,Work Hub,Works Connect, XML,Xen App,XenApp,Xmbrace, Yuneo,TS
Acutance Consulting, ...
No comments:
Post a Comment