Most service-business policy work has one of two failure modes, and the failure modes are opposite each other.
Failure mode one: the owner inherits a template policy handbook from a peer, prints it, hands it out at onboarding, and never looks at it again. Half the policies don't apply to the business. The applicable ones aren't tailored. Nobody owns enforcement. Six months in, the handbook is wallpaper. The compliance theatre is on paper, the real culture is whatever the team negotiated in practice.
Failure mode two: every uncomfortable situation becomes a new policy. Someone took too long on a personal call, write a phone policy. Someone left dishes in the sink, write a kitchen policy. Someone wore something inappropriate, write a dress policy. Eighteen months later the policy library is 60 documents long, contradicts itself in three places, and gets cited by team members as a sign that the business doesn't trust them.
The right policy work sits in the middle. Few policies. Each one earned. Each one tailored. Each one owned. The point of this article is the working test for which document is actually a policy, the baseline most service businesses need, and the ownership pattern that keeps the set alive.
Policy vs SOP vs guideline
Three different things, often labelled the same.
Policy
A rule the business is committed to, with consequences when it's broken.
Policies are about risk, compliance, ethics, or accountability. They define what's mandatory and what's prohibited. They typically reference statute, contract, or fiduciary duty. When a policy is violated, something specific happens, formal warning, retraining, escalation, or termination in the most serious cases.
Example: "Employees must not accept gifts or hospitality from suppliers worth more than $100 in a calendar year. Violations require disclosure within 48 hours and may result in formal review."
Standard Operating Procedure (SOP)
The steps to perform a task.
SOPs are about execution. They tell one person how to do one thing. The consequence of deviation is usually quality variance, not a formal review. Most "policies" in a typical handbook are actually SOPs.
Example: "To process an expense reimbursement: scan receipt, log in expense system, attach to project code, route to manager for approval, finance processes within 5 business days."
Guideline
A recommended approach.
Guidelines are about good practice. They suggest the way we like to do something but don't require it. The team uses judgement. No formal consequence for taking a different approach.
Example: "We recommend interviewing candidates with at least two team members for senior roles, to balance personal bias and surface different observations."
If your handbook treats all three as the same thing, you're either over-promising on guidelines (turning suggestions into commitments you don't enforce) or under-respecting policies (treating real rules like loose advice). The first error makes the business legally exposed. The second error makes the business culturally weak.
The test: when is a policy actually required?
Four questions. If you answer yes to any of them, the document is a policy. If the answer to all four is no, it's probably an SOP or a guideline.
1. Does a law, regulation, or contract require us to have this in writing?
Privacy, occupational health and safety, anti-harassment, financial controls, data residency in regulated industries. If the answer is yes, the document is a policy, and the wording usually needs to track the statute closely.
2. Does violating this expose the business to financial or reputational damage?
Conflicts of interest. Anti-bribery. Confidentiality. Use of AI tools with company data. Anything where the consequence of doing it wrong lands on the business as a whole, not just the individual.
3. Does this define a behavioural commitment the business is making to its people or its customers?
Anti-discrimination. Code of conduct. Equal opportunity. Customer service commitments. The kind of thing where the team needs to know the business will back them up and customers need to know what to expect.
4. Would inconsistent application cause friction across the team?
Time off. Expense limits. Remote-work parameters. Anything where different managers giving different answers to the same employee question would feel unfair. These need to be policy so the answer is consistent.
Apply the test before writing. A document that doesn't pass any of the four questions doesn't need to be a policy. Either write it as an SOP (if it's about how to do work) or a guideline (if it's about preferred practice), or don't write it at all.
The baseline set every service business needs
Most service businesses we work with end up with a working set of 10 to 14 policies. The exact list depends on industry, regulatory exposure, and team size, but the shape is similar.
| Category | Policies | Why required |
|---|---|---|
| People & conduct | Code of conduct; Anti-harassment / EEO; Workplace violence prevention | Legal requirement in most jurisdictions; defines cultural commitments. |
| Employment | Leave and time-off; Remote / hybrid work; Performance and discipline; Grievance | Consistency in application; required for fairness and many statutes. |
| Financial integrity | Conflict of interest; Expense and travel; Gifts and hospitality | Financial exposure; clarity for diligence; auditor expectation. |
| Data & technology | Privacy and data handling (PIPEDA / PIPA / GDPR as applicable); Acceptable use of tech and AI; Information security | Statute (PIPEDA, sectoral); contractual exposure; AI-specific risks new in last 24 months. |
| Safety | Occupational health and safety (industry-specific); Drug and alcohol (if regulated industry) | Statute; worksite safety; regulator requirement for many trades. |
Notice what's not on this list. There's no dress code policy. No phone-use policy. No kitchen-cleanliness policy. Those are guidelines at most, and usually not even that. The baseline is intentionally tight because every policy you add carries an enforcement obligation, and the team learns very quickly which policies are real and which are decorative.
The AI-and-acceptable-use policy is the newest addition for most businesses. If yours doesn't have one yet, that's the gap to close next. We covered the substance in The AI-Powered Workplace as Competitive Advantage; the policy version is the formal commitment.
Tailoring to your business
This is where template handbooks fail. A privacy policy lifted from a SaaS company doesn't fit a mechanical contractor. A code of conduct lifted from a 500-person company reads as legalistic in a 25-person team. A travel policy designed for a marketing agency doesn't anticipate field-service realities.
Tailoring is the part of policy work nobody enjoys and everyone needs. Four things to adjust:
1. The risk profile of your industry.
A construction-adjacent service business has occupational health and safety exposure that a software consultancy doesn't. A regulated trade has licensing implications a non-regulated one doesn't. A business with US clients has cross-border data implications. The policies need to reflect your risks specifically, not a generic template's idea of risk.
2. The actual texture of how work happens.
A remote-work policy at a field-service business isn't about "can people work from home" because most of the work can't be done from home. It's about office-based functions, what flexibility is offered, and how the rules differ for office staff and field crews. A generic template doesn't anticipate this distinction. Yours has to.
3. The language your team actually uses.
Policies written in legalese get ignored. Policies written in the language the team uses every day get read and remembered. Plain English. Specific examples. The same tone as your other internal communications, not a different register entirely. The lawyer reviews the substance. You own the voice.
4. The realistic enforcement.
If the policy says "violations result in immediate termination" and the business has never terminated anyone over a policy violation, the policy is lying. Either change the consequence to something you actually enforce, or commit to the consequence as written. A policy with an unrealistic enforcement clause is worse than no policy, because the team knows it's a fiction and learns to distrust the document set as a whole.
Who owns and "polices" the policy
The most common reason policies go stale isn't that they're written badly. It's that nobody owns them.
Every policy needs three named people, and a missing one is a problem.
Owner. The person responsible for keeping the policy current. They schedule the annual review. They decide when an event in the business requires the policy to be revised. They sign off on changes. For most policies, this is a leadership team member, not a junior staffer. Privacy policy might be owned by the CFO or COO; safety policy by the operations lead; code of conduct by the founder or HR lead. One name. Not a department.
Enforcer. The person who notices violations and handles them. Sometimes this is the owner, often it's a manager. Their job isn't to be the policy police; their job is to make sure consequences happen when they're warranted and the same situation gets handled consistently across the team. The enforcer needs documented authority to do this work, without authority, the policy is a wish.
Reviewer. The independent party that audits whether the policy is being followed. For most service businesses this is an annual exercise; the reviewer (could be the COO, an external advisor, or the board) samples a few situations and confirms the policy held up. Without a reviewer, the only signal you have about policy compliance is "no complaints have surfaced," which is a weak signal.
For each of the 10 to 14 policies in your baseline, name the three people. Put their names on the policy document. When ownership transfers (because someone leaves or changes role), update the document. Policies without named owners are policies in name only.
Common mistakes
Five patterns we see in nearly every policy assessment.
1. Too many policies. If your handbook is over 40 documents, most of them aren't policies. They're SOPs or guidelines or wishes. Shrink the policy library to the things that actually require the formal weight. Move the rest into the Playbook as SOPs.
2. Annual updates that never happen. Policies aren't write-once documents. The world changes, the business changes, regulations change. An annual review cadence per policy, owned by the named owner, is the minimum. Without it, the policy drifts out of step with reality, and the team's trust drains.
3. Confusion between policy and law. Privacy law (PIPEDA, PIPA) sets the floor for what you must do. Your privacy policy can commit to more, but it can't commit to less. If your policy says something the law disagrees with, the law wins, and you're now exposed for the difference. Lawyer involvement on the policies that touch statute isn't optional.
4. Enforcement inconsistency. Two employees commit the same policy violation. One gets a written warning, the other gets a quiet conversation. The team notices. The policy stops functioning. Consistent enforcement is harder than writing the policy, and it's the only thing that makes the policy mean anything.
5. Policies that nobody knows exist. The annual all-hands where the handbook gets distributed and forgotten doesn't work. Policies need to surface in the workflow where they're relevant. The AI-use policy referenced in the documentation hub. The conflict-of-interest policy referenced in the procurement procedure. The expense policy linked from the expense form. (We covered the broader pattern in Why Your Team Isn't Following the SOPs; the same logic applies to policies.)
The bigger frame
The job of a policy library isn't to cover every situation. It's to make the high-stakes situations predictable.
A small set of well-written, well-owned, well-enforced policies does more work than a thick handbook of vague commitments. The discipline is to keep the policy library small, the wording tailored, the ownership named, and the review honest. Everything else (the "how do we do things" stuff) belongs in the Playbook as procedures, where it can flex with the work.
If your current handbook is somewhere between failure mode one and failure mode two, the fix isn't another policy. It's a tighter library, taken seriously.