A Business Continuity Plan for Your Trades Business

A business continuity plan for a trades business should identify the work you must keep moving, who can make decisions, and how the team will operate when its usual systems or people are unavailable. Start with one disruption, write a usable fallback, and test whether the people doing the work can follow it.

Consider an illustrative HVAC shop on a busy morning. The dispatch platform is unavailable. Technicians are already on the road. A customer is waiting for a revised arrival window, and a supplier needs to know whether a part should go to the shop or the job. People can still work, but nobody has a dependable view of the next commitment.

The first useful plan does not need to cover every possible disruption. It needs to help this team make the next decision together. A backup of the schedule helps only if someone can retrieve it, explain how current it is, and record what changes while the normal system is down.

Decide which work cannot wait

Start with the service you need to preserve. For a service contractor, that might mean locating crews, reviewing urgent calls, and telling customers when they will hear from you. For a distributor, it might mean identifying time-sensitive orders and confirming which deliveries can still leave the branch.

The American Red Cross's rapid business impact analysis asks organizations to identify essential processes, decision authority, tolerable interruption, and the consequences of a delay. Apply those questions to one part of your operation before trying to document the whole company.

Bring together the people who see different parts of the same job. A dispatcher knows which promises are open. A technician knows what has changed in the field. A counter specialist knows which order is waiting on a supplier. Ask each person what information they would need if the usual screen disappeared.

In Robert Darling's conversation with Hugh, Darling describes treating employees as people who can spot problems early. He also emphasizes supporting the subject-matter experts closest to the problem. The editorial application here is practical: build the fallback with the people who will use it.

Choose a fallback the team can actually reach

A dispatch outage plan stored only inside the dispatch platform has an obvious weakness. Decide where the team can find the current instructions and the information needed to use them when that platform is unavailable.

The Canadian Centre for Cyber Security's continuity guidance recommends documenting response roles, communication methods, recovery procedures, and required resources. It also calls for keeping the plan securely accessible during a disruption and testing it regularly.

For the illustrative shop, the fallback might be an approved offline schedule snapshot and one controlled paper log. Decide who prepares the snapshot, how often it is refreshed, where it is kept, and who can access it. Mark when it was last updated. A yesterday-afternoon schedule should never silently become this morning's confirmed plan.

Check the fallback against a second failure. If it needs office internet, what happens when the connection is down? If the coordinator is absent, can the backup find it? Include only the customer and job details the team needs, restrict access, and follow your existing information-handling rules. Do not put account passwords on a shared job sheet.

Put one disruption on a continuity card

Use the worked card below as a Blue Collar Smart editorial exercise. The scenario is a confirmed dispatch-provider outage with phones still working. The roles and timings are illustrative, not a procedure endorsed by Hugh or Darling. Adapt them to your actual operation.

Name a coordinator and a backup. State what each person can decide under your existing authority rules. Identify the fallback record, the first customer update, and the condition that requires more help. A contact list is useful; a named person responsible for using it is better.

Be explicit about when this card applies. An unavailable service is not automatically a routine vendor outage. If there are signs of unauthorized access or another security incident, involve your IT or security support and follow the relevant incident procedure. Do not improvise a workaround through a potentially affected system.

Protecting people and following established emergency procedures comes first. Operational continuity does not mean sending a crew into unsafe conditions or assigning technical work outside someone's qualifications.

Keep customer updates tied to confirmed facts

Tell the team who owns outgoing updates so customers do not receive competing promises. The coordinator needs a record of who has been contacted, what was said, and when the next update is due.

An illustrative message might be: “Our scheduling system is unavailable. We are confirming today's visits directly with our crews. We will update you by 10 a.m., even if we are still working on your arrival window.”

That message gives a useful next step without pretending the outage is resolved. Choose a time the team can meet. If an arrival time is unconfirmed, record it as unconfirmed. Do not let a rough estimate turn into a customer promise as it passes from one colleague to another.

Ask the field team which calls need review under your established priority rules. Keep the person authorized to make those decisions visible. Clear authority matters most when several customers need an answer at once. Our article on delegating tasks in a trades business explains how to make those decision boundaries usable.

Reconcile the work before returning to normal

When the platform comes back, the paper log and the software may disagree. A technician may have completed a visit. Dispatch may have moved another job. A supplier may have confirmed a different delivery point.

Assign someone to compare the temporary record with the restored system before the team resumes normal scheduling. Check completed work, changed assignments, customer updates, open commitments, and anything still awaiting approval. Keep the fallback record available until the comparison is complete, then handle it under your retention and privacy rules.

Define who can announce the return to normal. Otherwise, one person may keep writing on paper while another starts making changes in software, leaving two versions of the same day.

Recovery is part of the plan. “The login works again” is a different observation from “the team has accounted for the work that happened during the outage.”

Run a twenty-minute tabletop exercise

Before relying on the card, sit down with dispatch, a field representative, and the backup coordinator. This is a discussion exercise. Keep the live systems running and use fictional job details.

• First five minutes: Read the outage scenario. Have the backup coordinator find the instructions and the schedule snapshot without help from the usual coordinator.
• Next five minutes: Add a changed appointment and an urgent customer call. Ask who decides, who contacts the customer, and where the update is recorded.
• Next five minutes: Say the platform has returned. Walk through how the team would reconcile the temporary log with it.
• Last five minutes: Record the gaps. Give each fix an owner and a review date.

The twenty-minute format is an editorial starting point, not a certification or a complete emergency exercise. Watch where people have to guess. Perhaps the backup cannot reach the schedule. Perhaps two people think they are responsible for updates. Those are useful findings while customers are not waiting on the result.

Review the card when a system, supplier, key contact, or responsibility changes. Use lessons from an actual interruption to improve it as well. A plan that depends on someone who left six months ago needs attention before the next busy morning.