Writing a Scope Statement That Protects Both Sides of a Field Job
Most disputes on field-service jobs do not start with bad work. They start with two people remembering the same job differently. The customer remembers a full network rebuild; the technician remembers replacing one switch and checking a cable run. A written scope statement is the simplest tool for closing that gap. It is a short, dated description of what the technician agreed to do, what was excluded, and what conditions the work depended on. This article explains how to write one for your own independent work, what it should contain, and what questions to ask before you sign off on anything. It is general educational guidance, not legal advice, and the wording you use should fit the way you actually operate.
Why the scope needs to exist before the visit
A scope statement is most useful when it exists before you arrive on site. Once a technician is standing in a server room or crawling under a desk, the pressure to add "just one more thing" is strong, and the customer may assume that anything nearby is included. Writing the scope first gives you a reference point to return to when the conversation drifts.
The document does not need to be long. For a typical job it can be a single page covering the site, the equipment or systems involved, the tasks you agreed to perform, the tasks explicitly excluded, the date and time window, and any access or power conditions the customer is responsible for. The exclusions are often more valuable than the inclusions. A line such as "firmware upgrades on the core switch are not included unless requested in writing" can prevent a great deal of later confusion.
Because you set your own rates, schedules, travel and responses, the scope is also where those decisions become visible to the customer. If you charge a minimum callout, state it. If you need a particular access window, state it. Treating these as ordinary parts of the written agreement, rather than surprises, is a sign of professional practice.
What a useful scope statement contains
Start with identification: the customer or site name, the address or location reference, the contact person, and the date the scope was written. Then list the systems or assets in question by identifier where possible, such as device labels, room numbers, or circuit IDs. Vague references like "the office network" invite disagreement about what was meant.
Next, describe the tasks in verbs you can verify. "Inspect and document the patch panel in rack B" is checkable. "Improve connectivity" is not. For each task, note what the finished state looks like, such as a labeled cable run, a test result recorded, or a configuration exported and saved. This turns the scope into a checklist you can close out against.
Finally, record assumptions and dependencies. Power availability, the presence of a site contact, the condition of existing cabling, and whether a change window has been approved are all assumptions that affect the work. If one of them turns out to be false, you want to be able to point to the written assumption instead of arguing from memory.
Handling changes during the job
Scope changes are normal in field work. You may find a failed device that was not on the original list, or the customer may ask for an additional task once you are on site. The discipline is to treat each change as a discrete decision rather than letting the scope quietly grow. Note what was requested, who requested it, the time it was requested, and whether you agreed to it.
A practical approach is to pause and write a short addendum before proceeding. It does not need to be formal. A message or a line on your job sheet, confirmed by the customer, is often enough to show what changed. If the change affects your time or travel, say so plainly. You decide how to price and schedule your own work, so the addendum is the place where that decision is recorded.
When you cannot reach the customer and a safety or data-integrity issue requires action, document the reason for any deviation, what you did, and what you left undone. Honest notes about why a task was not completed are more useful than a clean record that hides the gap.
A practical checklist before you accept a job
Before accepting a visit, check whether the scope names the systems involved, lists the tasks in checkable terms, and states what is excluded. Confirm that the access window, site contact and power or environmental conditions are stated, and that you have a way to record the date, time and the person who approved the scope.
Ask a few direct questions. Who owns the equipment and who has authority to approve changes? Are there any existing configurations or documentation you should review first? Is there anything on site that could make the work unsafe or impossible, and who is responsible for resolving it? Are there any deadlines that depend on your work, and has the customer described them clearly?
Compare this with how you normally work. If you already keep scope notes, check whether they capture exclusions and assumptions, not just tasks. If you do not keep them, start with one job and build the habit from there. The goal is not a perfect document but a consistent record that you and the customer can both read the same way.
Finally, remember that a scope statement is a working tool, not a guarantee of outcomes. It describes the agreed work clearly enough that everyone can tell whether it was done, what was left out, and why. Used consistently, it reduces friction, supports your own review of your work, and gives you a factual basis for any conversation about what was agreed.