Why Documented Procedures Stop Getting Used After Three Months

There's a folder on your computer called Company Procedures.

You built it over several weekends. You wrote the steps out carefully, you ran a training session, and for a few weeks afterwards people actually used it.

Then a client demanded a rush job, a key trade went missing, and an urgent variation needed pricing.

In that week nobody opened the folder. They rang you instead, because you were faster than looking something up, and once that pattern starts, it speeds up...

Three months later the folder is untouched and your team is asking you the same questions they were asking before you wrote any of it.

Documentation and a system aren't the same thing

Documentation is words in a file. A system is something your team uses daily to produce a consistent result, embedded in how the work actually happens, guiding decisions at the moment they get made. If nobody follows your procedures, what you've got is expensive paperwork, and your weekends paid for it.

APB's Systemising a Building Company Action Plan names three reasons systems get ignored.

The first is complexity. Thirty-page procedures nobody can use in the heat of the moment. Flowcharts that look like engineering diagrams, and instructions written like legal documents instead of practical guides.
The second is disconnection from outcomes. People can't see why the procedure matters or how following it makes their own job easier, so under pressure it reads as optional extra work.
The third is neglect. The first time somebody follows a procedure and hits an outdated step or a dead link, trust in the whole manual goes. If the system isn't current, there's no reason to rely on any of it, and people go back to asking the person who definitely knows.

Somebody has to own it, and ideally it isn't you

The structural fix is a named role. David Jenyns' calls it the Systems Champion in his book Systemology. Documentation that belongs to nobody in particular drifts out of date and dies, while a manual with one accountable owner keeps getting corrected and used.

The Systems Champion captures how work actually gets done, keeps it organised in one place, and trains the team to use the systems rather than coming to you with every question.

The role needs organisational skill, attention to detail, curiosity, persistence, comfort with technology, and a genuine belief that systems make everyone's job easier. The right person isn't necessarily your most experienced tradesperson. You want your most systematic thinker.

At a smaller size this is you wearing another hat, or your most organised team member taking it on part-time. As the company grows it becomes a dedicated position covering creation, maintenance, training and adoption across sales, marketing, operations, financials, team and client experience.

The trap is trying to be both the system creator and the Systems Champion. If you're writing all the procedures and personally running all of them, you've reorganised the bottleneck rather than removed it. The manual now exists, but everything still routes through you.

Anchor every system to a real moment

Procedures get ignored when they float free of the situations they're meant to govern. The framework we recommend to prevent that is trigger, tool, outcome.

Every working system starts with a trigger, meaning the specific event that sets it off, such as a new enquiry coming in, a job reaching lock-up, or a client asking for a variation. The tool is what your team reaches for in that moment, whether that's the standard operating procedure (SOP), the checklist or the template. The outcome is the consistent result you get every time.

Client complaints show how tight this can get. The trigger is any client expressing dissatisfaction, by phone, email or in person. The tool is the client complaint SOP, supported by a response checklist and follow-up email templates. The outcome is a documented issue, an immediate acknowledgement to the client, an investigation completed within 24 hours, and a resolution plan communicated.

Without that structure, complaints get handled according to whoever picked up the phone. Some get resolved quickly while others drag on, and some clients feel heard while others feel ignored. With it, every complaint gets the same professional response regardless of who takes the call first.

Build maintenance into the document itself

Neglect, the third reason systems get ignored, is dealt with inside the procedure.

Name an owner, and name the role rather than the person, so the procedure survives someone leaving. State the frequency, meaning whether this happens daily, weekly, monthly or on a trigger. Write down why it matters, connecting the process to protected profit or a better client experience, because that's the field that answers the disconnection problem above.

Include troubleshooting, covering the common ways it goes wrong and what to do, so the first unexpected situation doesn't send someone to your phone. And keep document control, meaning a version number, who last updated it, the date, and a note on what changed.

Keep an SOP to one page where you can. If a process genuinely needs more depth, split it into parts rather than letting one document grow to thirty pages.

Replace job descriptions with role clarity

Most building companies run on job descriptions, and a job description is a vague list of duties along the lines of managing site operations, coordinating with trades and maintaining quality standards. None of that tells anyone what they own or how they'll be judged.

Role clarity connects the position to specific systems and specific outcomes instead. Rather than "manage site operations", it reads as owning the daily site management system, with a scorecard covering schedule adherence, safety incident rate and variation capture accuracy, and a named set of SOPs the person is accountable for following.

That's the difference between telling someone to do their job and telling them which systems are theirs. Once a person has clear ownership of a process and a measurable outcome attached to it, they stop waiting for permission to act inside it.

If you're working out which numbers belong on those scorecards, 12 KPIs every builder should track is a reasonable starting shortlist. If you haven't written company policies to sit alongside those systems, how policy works in a building company covers the basics.

Let the team fix the procedures

Your site managers know exactly where processes break down. Your admin team knows which steps slow everything else up. A procedure written without their input will have gaps you can't see from your desk.

So ask, but ask at the right time. Get feedback after a system has been in use for a few weeks, and ask what's working, what's confusing and what would make it faster.

When somebody can't complete a process, fix the system rather than the person. Do the same when a system is being skipped. Start with curiosity and ask what prevented them from using the process, then remove the barrier, add the training, or tighten the SOP if a step was genuinely unclear.

Don't try to manage this yourself. Your Systems Champion coordinates the feedback and the fixes while you keep oversight.

Start smaller than feels adequate

You don't need perfect systems on day one. Start with the simplest version that captures the essential steps and produces a consistent result, then refine from real use, adding detail where people get stuck and cutting steps that cause confusion.

If you want help systemising your building company, book a 15-minute chat with our team.