Jobber
Jobber is field-service management software that some businesses try and abandon when the crew using it in the field is not brought into the decision.
Jobber is field-service management software: scheduling, dispatching, invoicing, and the day-to-day coordination between an office and a crew working out in the field. It is a real, capable tool, used successfully by plenty of service businesses. It is on this glossary because of a specific failure I saw, not because the software itself is the problem.
I have seen Jobber tried and abandoned before I ever arrived. The office sets it up carefully and moves the bookings into it. The field crew, the people who would actually be using it every single day on the job, are not part of that setup process. When it reaches them, they reject it, and the business quietly slides back to the shared calendar and manual process it used before.
That is not really a story about Jobber. It is a story about what happens when a new system is decided in the office and handed to the field as a fact rather than tested with the people who have to live inside it.
Why it matters to you
Any new system, whatever the software, lives or dies on whether the people using it every day actually adopt it. A tool that is technically correct but rejected by the crew ends up worse than no change at all, because now there has been a failed attempt, some wasted setup time, and a crew that is more skeptical of the next tool that comes along.
This matters just as much for a website change as it does for field software. If a new lead process or booking flow does not fit how the people receiving those leads actually work, it will get worked around, not adopted.
What I do about it
Before I roll out any change to how a business handles jobs, whether that is a new lead flow from the website or a change to how bookings move into the field, I test it with the people who will actually use it. Not after launch, before it. That is the exact step that was skipped with Jobber, and skipping it is what caused the failure, not the software.
For the system of record that eventually replaces a shared calendar, the same rule applies. A crew view has to be tested with the field guys before rollout, not after, because a system nobody in the field trusts becomes a system nobody in the field uses.
What it looks like in practice
Before: office decides on a system, sets it up, moves the bookings in, and hands it to the crew as a finished decision. The crew rejects it, and the business is back where it started, minus the time spent setting it up.
After: whatever new system replaces the old process gets built and tested with the crew’s involvement from the start, so by the time it rolls out, it already fits how they actually work.
Questions I get about this
- Is Jobber bad software?
- No. It is a capable tool that plenty of field-service businesses run successfully. In the case where I saw it fail, the software was not the problem. It was rolled out to the office without the field crew ever being brought in, so they rejected it once it reached them.
- What went wrong specifically?
- The office set it up and moved bookings into it, but the people actually doing the jobs in the field were not part of that process. When a system does not fit how the crew actually works day to day, they stop using it, and the office ends up back on whatever they used before.
- How do you avoid that happening again?
- I test any new system with the people who will actually use it in the field before rollout, not after. That was the step Jobber's rollout skipped, and it is the one I build into any change I make to how a business runs its jobs.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.