Will my crew actually use new software?
Straight answer up front. Then the details.
The short answer
Only if it makes their day easier within the first week. Crews don't resist software — they resist extra work. If updating the system takes longer than the text they used to send, they'll send the text, and the software becomes an expensive office diary.
Adoption is designable. It fails when it's treated as a training problem instead of a fit problem.
Why capable software still fails in the field
The demo happens on a big screen in a quiet office. The job happens on a phone, with gloves, in glare, between tasks. Software that's excellent in the first setting can be unusable in the second — and no amount of training fixes a tool that fights the conditions it's used in.
The usual failure modes:
- Updating the system is slower than the old text or phone call
- It demands typing where a photo or a tap would do
- The crew can't see what's in it for them — only for the office
- Nobody owns adoption, so it quietly becomes optional
- Training was generic instead of role-specific — everyone learned everything, nobody learned their part
The field usability test
Run this against any software you're evaluating — or the one you already own. Every "no" is a place adoption will leak.
Nine checks, on the actual device, on an actual site:
- Can a crew member complete the core action — update a job, log a change — in under a minute?
- Does it work on the phones your crew actually carries, not the newest one in the demo?
- Can it be operated with minimal typing — taps, photos, voice where it counts?
- Can anyone see a job's status in five seconds, without asking?
- Does it behave sanely on a weak signal, if your sites have them?
- Is it obvious who's responsible for what — or does the tool blur ownership?
- When an exception happens, is there an in-app path — or does it force a phone call?
- Is training role-specific — crew leads learn their three screens, not all thirty?
- Does one named person own adoption, with the authority to kill the old channels?
A rollout that sticks
Six steps, in order — skipping one is where rollouts die
- Pick one crew and one championA respected crew lead who wants it to work beats a company-wide memo every time.
- Start with one workflowJob status updates, or scheduling — not everything at once. One habit at a time.
- Train by roleFifteen minutes on the three screens each person actually uses. Not a two-hour tour.
- Run parallel — brieflyOld channel and new system together for one or two weeks. Long parallels kill adoption; set an end date.
- Kill the old channelThe hard step. As long as texting the owner still works, the system is optional. Ownership means turning the old way off.
- Review at two weeksAsk the crew what's slower than before — and fix that, not the feature list. Then expand.
Who owns adoption
Not the vendor, and not "everyone." One named person — often the owner at first, better a champion — owns it: they check that the system is the truth, they close the old channels, and they carry crew feedback back into how the tool is set up. This is also why systems built with the crew's input adopt better than systems bought for them: the people doing the work can tell you in one site visit what a demo never will.
ACS guidance — written from operator experience building systems for contractors, not from vendor marketing. Last reviewed August 10, 2026.
Our approach
We design systems around your business.
Built from inside the operation—not from the sidelines. The people doing the work help shape the system.
- Listen
- Map
- Build
- Test
- Refine
Worked with Connor
He Helped Me Believe
Robert shares how working with Connor helped him believe in himself, gain clarity around his purpose and begin turning his mission into something real.
Watch Robert’s storyWhere to go from here
Not sure which side you’re on?
Walk through the Systems Audit and we’ll point you in the right direction — even if the answer is a tool you already have.
Take the Systems Audit- About two minutes
- No sales call required