Electrician How-To Lesson · Electrical contractors, foremen and office teams
Imagine a contractor trying to solve a scheduling problem. The office changes tomorrow's assignment. A foreman has an older version. An electrician follows a text message sent before the change. Everyone has information, but they are working from different information.
Someone suggests another app. The demonstration looks organized. The team gets excited. Yet nobody has answered the most important questions: who updates the assignment, where does the current version live and how does the crew know it changed?
This is a hypothetical example, not a claim about a particular company or software product. A tool might help, but the team still needs a process it can explain and practice.
Before comparing features, define one piece of work you want the tool to support. Then test whether people can use it successfully under real working conditions.
What you will get from this lesson
You will leave with:
- One clearly defined workflow, rather than a shopping list of apps.
- An owner responsible for a small, controlled test.
- A simple baseline and evidence to review afterward.
- A decision to keep, adjust or stop the test without pretending a demonstration proved the result.
The finished takeaway is a written pilot plan. You can start with a tool your company already has. This lesson does not require a purchase or recommend a particular product.
1. Name the problem in work terms
“Get more organized” is too broad to test. Describe what someone needs to do and where that action currently breaks down.
For example: “When the office changes tomorrow's crew assignment, the foreman needs to find the current version and acknowledge the change before the crew acts on it.”
Now you can identify the actual problem. Perhaps the change is never recorded. Perhaps it is recorded in several places. Perhaps nobody is responsible for checking it.
Talk with both sides of the handoff. A system that makes the office's screen cleaner but adds unnecessary field work has not automatically improved the process.
2. Describe the workflow before the features
Write down the trigger, the required information, the responsible person and the completed result. Keep the scope small enough to practice with one example.
For the scheduling example:
- Trigger: an approved assignment changes.
- Input: the affected job, people, timing and explanation needed by the crew.
- Owner: the person authorized to maintain the schedule.
- Action: update the agreed record and notify the affected team.
- Completion: the receiving person can identify the current assignment and acknowledge it.
Agree on which record is authoritative. During a test, a second tool must not quietly become a competing schedule. Explain whether the pilot is a demonstration using fictional records or an authorized live workflow. If it is live, define how discrepancies will be resolved.
The weekly crew scheduling lesson covers building the schedule. This lesson covers testing the process used to communicate and maintain it.
3. Match a tool to the job it must do
Our original BULD June Workbook includes a schedulers toolkit on page 10 and the assignment: “Pick one tool to test and review.”
Start by checking what your company already uses. Can it support the agreed workflow? Can the field team access the necessary information? Can the responsible person correct an error? Can you retrieve your records if the process changes?
Use a short list of requirements tied to the actual work. For this pilot, viewing the current assignment and acknowledging a change may matter more than a long list of unrelated features.
The workbook's software list belongs to its original 2025 course context. It is not a current comparison, pricing guide or endorsement. This article evaluates a workflow; it does not rank software or tell you to buy a subscription.
4. Give the pilot an owner and a boundary
A pilot needs someone who will answer questions, observe difficulties and lead the review. “Everyone will try it” usually leaves those responsibilities unclear.
Write down who participates, what work is included and when the team will review the result. Choose a manageable interval and a small, representative set of tasks.
Use fictional sample data for an initial walkthrough. Before using real records, follow your company's approval and access process. Keep passwords, payment information and unnecessary customer details out of demonstrations. Do not upload a customer list just to explore a feature.
Also define a fallback. If the test stops working, where will the team find the current instruction? Who communicates the change back?
5. Collect evidence instead of enthusiasm
Before the pilot, observe a few comparable examples of the current workflow. Record what happened: whether information was complete, whether the receiving person found it and how many clarification steps were needed.
During the pilot, collect the same observations. Note training time, extra entry work and problems as well as improvements. A faster task for one person may have moved work onto somebody else.
Keep the comparison honest. A quiet week with simple jobs is not the same test as a crowded week with repeated changes. A small pilot can show whether a workflow is usable; it does not prove a company-wide productivity gain or a financial return.
Ask each participant: “What could you complete without asking for help? Where did you get stuck? What did you have to enter twice?” Those answers give you something concrete to improve.
Do this: complete one test-and-review plan
Download the original BULD June Workbook and open the schedulers toolkit on page 10.
On a separate sheet, complete these prompts:
- The one workflow we will test is ______.
- The current breakdown we observed is ______.
- The pilot owner and participants are ______.
- The information we need, and do not need, is ______.
- We will know the task is complete when ______.
- We will compare these observations before and during the pilot: ______.
- Our review date and fallback process are ______.
These prompts are an article exercise expanding the workbook's short assignment. They are not a form printed in the unchanged original PDF.
At the review, choose one outcome: keep the tested workflow, adjust one specific weakness and test again, or stop because it did not meet the need. Write down the reason.
Build a system people can actually use
The useful result is a team that understands the work, the record and its responsibilities. Software can support that result. Your people still need practice, feedback and a shared definition of completion.
Bring your pilot findings into your next team conversation or BULD learning discussion. Share what you tested, what happened and what you changed. That is more valuable than collecting another unused tool.
I’m Wilson Matthew Betances, and my mission is simple: Building the People Who Build Things. Take one thing from this lesson and put it to work. If it helped, keep learning with us.