Getting the Team on Board

Most operational changes fail not because the new system is bad, but because the rollout is bad.

Why Changes Fail in Trade Businesses

55–75% of technology implementations fail when driven by top-down mandates (Rand Group, cited by ACCA). The owner comes back from a conference, announces "we're doing it this way now," and expects the team to switch by Monday. Two weeks later, nobody's using the new process.

Resistance follows predictable patterns:

• "We've always done it this way." 10+ years of one method — no reason to change what's been working.
• "That won't work in the field." Sometimes legitimate. Often means "I haven't tried it and don't want to."
• "I'm too busy to learn new stuff." Translation: "I don't see how this helps me."
• "This is just micromanagement." Experienced crews view new tracking as the owner not trusting them.

The common thread: people resist changes they don't understand, weren't involved in, and can't see benefiting them.

Five Steps That Work

Kotter's 8 steps, Bridges' Transition Model, and Prosci's ADKAR all converge on the same core principles. Translated to contractor language:

Step 1: Show the problem first

Before announcing any change, show the team why the current way isn't working. Use their own numbers:

• "We had 47 callbacks last quarter. Each one cost $800+ and took a tech off the board for half a day."
• "We're losing $40K a year in unbilled time."
• "Our close rate is 28%. Industry average is 40%. That's $180K we're not getting."

The team needs to feel the problem before they'll accept a solution. Skip this step and the change feels like punishment.

Step 2: Explain what's in it for them

Every person affected is silently asking: "What does this mean for me?"

Step 3: Pilot with the willing

Start with 1–2 people who are open to trying new things. The pilot catches problems early, creates proof (when the pilot tech's ticket goes up $200 in three weeks, that's evidence), and creates champions — a tech telling another tech "this actually works" is 10× more persuasive than the owner saying it.

Step 4: Train by doing, not by telling

• Ride-alongs. Manager demonstrates the new process on a real call.
• See one, do one. Trainee runs the next call with trainer observing.
• Repetition over 30–60 days. One session changes nothing. Reinforce weekly.
• Low-pressure practice. Give software access well before go-live — let people click around without consequences.

Step 5: Hold through the dip

Performance drops before it improves. This is the #1 reason owners abandon good changes too early.

Five Common Changes (and How Each One Fails)

New price book

The hardest change. Techs who've quoted by gut feel like they're "overcharging." The resistance is about self-image — they see themselves as helpers, not salespeople. Presenting a $1,200 repair feels wrong when they used to quote $600.

Fix: Show them the loaded labor rate math. Use menu-style presentation (Good/Better/Best) so the tech shows options, not a price. Start with the willing. Expect 60–90 days of discomfort.

New software

Owner buys ServiceTitan, schedules one training session, expects everyone to use it Monday. ServiceTitan's own implementation takes several weeks to months with dedicated implementation managers.

Fix: Set up 2–4 weeks before go-live. Start with dispatching/scheduling only. Add features in 2-week cycles. Assign one power user per role.

New pay structure

Money is personal. Any change triggers anxiety, even when total comp goes up. Loss aversion: the guaranteed $30/hr feels safer than the potential $38/hr with bonuses.

Fix: 90-day parallel track — old structure guaranteed, new structure tracked alongside. Show each person what they would have earned. Make first spiffs easy to hit. Never reduce base pay to fund performance pay.

New customer interaction process

The 15-year tech doesn't want to become a "salesperson."

Fix: Reframe — "you're informing, not selling." Show the income math: options presentation averages $800–$1,200/call vs. $300–$400 repair-only. Start with one element (always present three options), add one per month.

New documentation requirements

Techs hate paperwork. Adding forms or photo requirements feels like busywork.

Fix: Explain the cost of not documenting ("we lost three warranty disputes — $8,400"). Make it the easiest possible step — photo capture, checkboxes not narratives. Build it into the workflow (software requires photo before invoice submits).

The Owner's Role

None of this works if the owner isn't visibly committed. "Committed" means:

• Using the new system yourself — not asking for reports from the old one
• Attending the same training as the team
• Asking about the new metrics in huddles, not the old ones
• Celebrating early wins publicly
• Not making exceptions for yourself or favorites