We're only 30 people. Are we too small?

Probably not, but the shape matters more than the size. Under about fifteen we'd usually suggest one tight piece of work rather than anything ongoing — and we'd tell you that rather than selling around it.

We already have ServiceTitan and barely use it.

Extremely common. These platforms are deep and most are half-configured, so the field team builds workarounds and the data never becomes trustworthy. Fixing the configuration is nearly always cheaper than switching.

Our technicians won't use an app.

They will if it's faster than the paper, and they won't if it isn't. That's why we watch the work first — people build workarounds for real reasons, and designing around those reasons is how these projects fail.

What if our key person leaves before we start?

Then move faster, and say so when you call. Capturing a process from someone still in the role is dramatically cheaper than reconstructing it after they've gone.

AliveCommerce / Industries / Trades and contracting

Trades and contracting

Dispatch works because one person knows every customer, every technician and every job. It has worked that way for years and it will work until the day she retires, at which point roughly forty percent of the operation leaves with her.

Common platformsServiceTitan · Jobber · Simpro · QuickBooks

Frequent triggerA key person leaving

Typical size15 to 60, mostly in the field

What we see most.

Tick what applies. The count changes what we'd recommend, and sometimes the recommendation is to wait.

What we do here.

Across all three layers, because problems in this sector rarely stay in one.

Knowledge and process

Dispatch logic, service procedures and field documentation

The most valuable thing in a trades business is often undocumented: who to send, how long it takes, what usually goes wrong at that site.

Dispatch and scheduling logic captured
Service procedures and safety documentation
Technician onboarding that isn't shadowing
Warranty and compliance record systems

Applications

Field platforms, quoting and job costing

Field service platforms are powerful and frequently half-configured, so the field team works around them and the data never becomes reliable.

ServiceTitan, Jobber and Simpro configuration
Quoting and estimating tools
Job costing reporting that arrives during the job
Integration to accounting and payroll

Web and revenue

Booking, customer communication and local presence

Most trades websites are brochures. The useful version books work, confirms appointments and reduces the calls that interrupt dispatch.

Online booking and appointment confirmation
Customer service history access
Local search and accessibility compliance
Quote request and follow-up flows

The systems you probably run.

Each has a page on Champion1 covering what typically breaks and what we do about it.

ServiceTitan Jobber Simpro FieldEdge QuickBooks Xero Monday.com Custom dispatch tools

Who we usually work with.

And the sentence that tends to start the conversation.

Owner / PresidentUsually the buyer at this size“If she leaves, we're in real trouble.”

VP Service / Service ManagerOwns first-time fix rate“Why did we send someone twice?”

DispatcherOwns the day, entirely“It's all in my head and that's fine until it isn't.”

Office ManagerOwns the paperwork“I'm typing up job sheets three days after the job.”

What it looks like in practice.

Trades · 35 staff · ongoing

Dispatch ran on a whiteboard and one person's memory

She retired in March. Eight weeks to get what she knew into something the rest of the crew would actually use in the truck.

Zero

missed calls since

Straight answers.

Related.

The capabilities this sector reaches for most.

Onboard and train faster“Six weeks before a new hire is any use.”Get off paper“Filing cabinets, carbon forms, binders on the shop floor.”Reduce manual work“The same data gets typed into three systems.”

Tell us what's breaking.

We'll tell you which part of this we'd put on it, roughly what it costs, and whether it's worth doing at all — including when the honest answer is that you don't need us.

Start the Conversation

Knowledge and process

Applications and data

Customer and web

Browse by symptom instead

The structure

Continuous ownership

Before you commit

Start with one problem

Priority sectors

Also

Or by situation

Not sure you fit?

Reading

Most read

Proof

Nobody owns the application layer