Standard Operating Procedures: Core Work

Why this matters

Every service business runs on repeatable work. Quoting a fitout job, onboarding a new hire, closing a project and collecting final payment. These tasks happen dozens of times a month, but in most companies with 10 to 60 people, the method lives in someone's head.

That is the problem. When the method is tribal knowledge, quality depends on who is working that day. New hires take three months to get up to speed because nobody wrote down how things actually get done. The best people on the team spend their time answering the same questions instead of doing higher-value work.

The ARCAS diagnosis flags this through the Conversion and Skills audits. Low scores in those areas usually trace back to the same cause: no written standard for the work that pays the bills. The Five Levels model calls this systems leakage. Revenue leaves the business because nobody agreed on the steps and the steps changed each time the work was run.

A short, clear document that says "here is how we do this" changes how fast people learn, how consistent the output is, and how much founder time gets freed up. The change is incremental rather than total, and it builds in months rather than weeks.

A founder you might recognise

A founder runs an MEP contracting firm in Abu Dhabi. 38 staff across three sites. The senior project manager has been with the company nine years and knows every client preference, supplier quirk, and shortcut for getting municipality approvals on time.

Last year the senior PM went on medical leave for six weeks. Within ten days, two projects missed submission deadlines. A junior engineer sent an incorrect BOQ (bill of quantities, the line-by-line list of materials and labour priced into a construction or fitout project) to a client because he did not know the internal review step. The founder spent his evenings on WhatsApp putting out fires the senior PM would have caught at 8am.

The team was not incompetent. The senior PM's method had simply never been written down. When the founder sat with him after his return and documented the five core processes, new engineers started handling submissions independently within three weeks instead of three months. The cost of those six weeks of chaos was roughly AED 180,000 (USD 49,000) in rework and penalties. The cost of writing five SOPs was two afternoons.

Process vs. SOP: know the difference

A process is the big picture. "We do site inspections." That is a process. It tells you what happens but not how.

An SOP is the specific method. It tells you who does what, in what order, using which tools, and what the output looks like. "The site engineer takes 12 photos using the inspection checklist in Zoho, uploads them by 4pm, and tags the project manager for review" is an SOP.

Most companies have processes. Few have SOPs. The gap between the two is where mistakes, rework, and client complaints live.

The 70% rule: when to document

Not everything needs an SOP. If you try to document every task, you will burn out and your team will ignore the whole effort. Use the 70% rule: if a task happens at least 70% the same way each time, document it.

A client proposal has a standard structure, standard pricing logic, and standard approval steps. It varies by client, but the bones are the same. That is a 70% task. Write the SOP.

A negotiation with a difficult landlord on a unique lease term is mostly judgment. That kind of work fails the 70% test. Leave it to the experienced person and move on.

Here is a quick filter. Look at the work your team does this week. For each task, ask: could a competent new hire do 70% of this correctly with a written guide? If yes, it needs an SOP. If the answer is "no, it requires years of relationships and judgment," it does not.

Writing SOPs people actually follow

The reason most SOPs collect dust is that they were written by someone who does not do the work. A manager sits in a meeting room, writes a 14-page document with flowcharts and approval matrices, emails it to the team, and wonders why nothing changes.

Three rules for SOPs that stick:

The person doing the work writes the first draft. They know the real steps the way the work actually runs. The founder's role is to edit, polish, and approve.

Keep it short. One page maximum. If an SOP is longer than one page, it is either covering too many tasks or including detail nobody needs. Break it into smaller SOPs.

Use visuals for multi-language teams. In the UAE, your team likely includes people whose first language is Arabic, Hindi, Urdu, Tagalog, or Malayalam. A numbered list with photos or screenshots works better than three paragraphs of English text. A 90-second screen recording of the Zoho workflow beats a written walkthrough every time.

The 70% compliance principle

An SOP followed 70 percent of the time beats a perfect SOP followed never. The team will skip steps. Eight-step invoice SOP, team consistently follows six of the steps, you have already cut errors compared to having no SOP at all.

Chasing 100 percent compliance on day one kills the discipline before it sticks. Track which steps get skipped and ask why. Sometimes the step is unnecessary. Sometimes the tool is clunky. Fix those causes and compliance rises on its own.

Progress is what keeps an SOP program alive.

The SOP template

Use this structure for every SOP. It maps directly to the SOP Starter tool at /resources/sop-starter, which gives you a fillable version you can hand to any team member.

That is the whole template. Seven fields. If you cannot fit an SOP into this structure, the task is too broad. Split it.

Common mistakes

Writing SOPs for everything at once. Start with your top five revenue-generating tasks and land those before moving on. The team that tries to document 30 SOPs in a quarter ships none.

Making SOPs too detailed. An SOP that says "open Chrome, click on the address bar, type zoho.com" insults your team. Write for a competent adult who knows the basics but not your specific method.

Never updating them. An SOP written 18 months ago for a tool you no longer use creates confusion. Set a calendar reminder to review each SOP every quarter. The owner spends 15 minutes confirming it is still accurate.

Skipping the rollout. Writing the SOP is half the work. The other half is a 10-minute team walkthrough where the owner explains it, the team asks questions, and you agree on when it takes effect. Without this step, the SOP is just a file nobody opens.

Treating SOPs as control tools. If your team sees SOPs as surveillance, they will resist. Frame them as training tools: "This is how we help new people get good fast." That framing changes everything.

SOPs and Emiratisation compliance

If your company falls under MOHRE's Emiratisation requirements, SOPs are not just an efficiency tool. They are compliance documentation. MOHRE audits check whether Emirati roles are real, structured, and backed by evidence the work actually exists. If an auditor asks what a role involves and the answer is "it depends" or "ask the manager," that role looks like a paper placement.

An SOP for each role occupied by an Emirati hire proves three things: the role has defined responsibilities, there is a training path a new person can follow, and the work is real. This is especially important during the first year of an Emirati employee's tenure, when turnover risk is highest. A clear SOP shortens time to productivity, which improves retention, which keeps your MOHRE ratio intact. The cost of writing these SOPs is a fraction of the AED 96,000 to AED 108,000 (USD 26,140 to USD 29,410) annual fine for non-compliance, and far less than the hidden cost of replacing an Emirati hire who left because the role had no structure.

When you prioritise which SOPs to write first, include any role currently filled or planned for an Emirati national alongside your top five revenue tasks.

When to move on

You are ready to move past this chapter when:

• Your top five revenue tasks each have a one-page SOP
• Each SOP has a named owner
• New hires can reference SOPs during their first week
• You have reviewed and updated at least one SOP based on team feedback

You do not need every task documented. You need the critical ones documented and used. That is enough to move forward.

Where to focus by team size

• 10 to 19 people: Write 3 SOPs for your most repeated processes. Start with the ones new hires ask about most.
• 20 to 34 people: Aim for 10 to 15 SOPs covering your core delivery. This is the minimum for consistent quality.
• 35 to 50 people: SOPs should be owned and updated by the people doing the work, with the founder as editor.

---

Working prompts

People

• Who on your team knows a critical process that nobody else can do?
• If that person left tomorrow, how long would it take to recover?
• Which team members would be best at writing the first draft of an SOP for their own role?

Systems

• What are the five tasks that generate the most revenue or protect you from the most risk?
• Which handoffs between team members cause the most errors or delays?
• Where do you see the same mistake happening more than twice a month?

AI

• Which SOPs could include a short video or screen recording instead of written steps?
• Once your SOPs are written, which ones could be turned into Zoho workflows or automated checklists?
• Where would a simple template or form reduce the need for someone to remember the steps?

Founder exercise

Part A: Identify your top five (15 minutes)

List the five tasks in your business that happen most often and have the highest impact on revenue or client satisfaction. For each one, write down: who does it now, whether a written method exists, and what happens when that person is absent.

Part B: Write one SOP (30 minutes)

Pick the task from Part A where the gap is largest. Sit with the person who does it and fill in the seven-field template above. Do not edit for perfection. Get the real steps on paper. If you have a multi-language team, ask the person to sketch the steps or record a voice note in their first language, then translate the key points.

Part C: Test it (1 week)

Give the SOP to someone who has never done the task. Watch them try it. Note where they get stuck. Update the SOP based on what you observe. If they can complete the task at 70% quality on the first attempt using only the SOP, you have a working document.

ARCAS lens

The diagnosis engine surfaces SOP gaps through the Conversion audit (are your revenue-generating processes consistent?) and the Skills audit (can the team execute without constant supervision?). When the Five Levels model shows systems leakage, SOPs are usually the first fix. The intervention is writing down how the work gets done, by the people who do it, in a format short enough that someone will actually read it. Not software or hiring.

The same artifact that lets a new hire run the work in week one is what lets a future tool or agent participate without inheriting the institutional memory the senior team carries today. The team is the first reader and the most important one. The artifact makes every later reader possible.

The SOP Starter tool at /resources/sop-starter gives you the template in a ready-to-use format. Start there.

Start now: quick self-assessment

Score each row from 1 (not true) to 4 (fully true). Add your scores.

20-24: Your SOP foundation is solid. Focus on expanding coverage to secondary tasks and building review cycles.

13-19: You have some documentation but gaps remain. Prioritise the exercises above for your highest-risk processes.

6-12: Most of your operational knowledge is tribal. Start with Part B of the founder exercise this week. One SOP for your single most important task. Build from there.