The engineering of operating policies

The engineering of operating policies

Every organisation has an approved policy that nobody consults. It sits in the shared folder, carries management's signature, is shown to the auditor each year, and then goes back to its place. When an employee faces a real decision they do not open it. They ask a colleague or a manager. So what is the use of a policy that is not used at the very moment it was written for?

This article argues that an operating policy is designed differently from a report, and that it is a decision tool before it is a written text. In it you will learn six steps to build one: name the decision, say who owns it, specify the inputs it needs, set the constraints, define the consequence of override, and make the policy appear at the moment of decision. We will follow one hypothetical case from start to finish: Hind, the operations centre she runs, and an urgent-orders policy that nobody used.

A paper with an approval stamp

Hind runs the operations centre at a distribution company. Every day urgent requests reach the centre: a customer wants a shipment earlier than planned, another wants an address changed after the truck has left, a third wants an item added at the last minute. The company has an urgent-orders policy, approved two years ago, nine pages long.

One morning a major customer called wanting a shipment moved forward by two days. The coordinator, Omar, did not open the policy. He told himself: this is an important customer and I will not risk it. He agreed at once and rearranged the truck schedule. That afternoon Hind discovered it had delayed three other customers, and the company bore extra transport costs.

Hind asked Omar: did you not read the policy? He answered honestly: I read it the day it came out, and I do not recall anything in it that helps me now. Hind opened the document and found passages on commitment to customer satisfaction and coordination between the departments concerned. But she did not find one sentence saying when an urgent request is accepted and when it is refused.

“A policy that no one consults is not a policy; it is paper.”

Where the case stands now

Hind has an approved policy, an employee it did not help, and a real loss in a single day. She understands that obliging staff to read the policy will not solve it, because the policy itself does not answer the question Omar asks every day.

“Take five minutes now: choose a policy in your organisation and write a real question an employee faces every week. Then search the policy for the answer and see how long it takes.”

Why are policies written like reports?

Had we asked the author of the urgent-orders policy how he worked, he would have said he followed the approved template, gathered the departments' views, and drafted a text that pleased everyone. That is true, and it is also the cause of the failure. The policy was written to satisfy an approval process, not to help an employee decide.

A report serves a reader who wants to understand what happened. An operating policy serves someone who wants to decide what will happen. These are quite different readers. The first reads seated and has time; the second stands before a customer awaiting an answer. If we write for the second in the style of the first, we get general phrases that cannot be used, such as urgent requests are handled in line with approved controls.

There is another reason that many overlook: the general phrase is safe. Whoever wrote in a way that achieves customer satisfaction cannot be faulted, and nobody can apply it. Whoever wrote that an urgent request is not accepted if it delays more than two shipments has taken a risk, since someone may object. So authors choose safety, and the employee pays.

You know your policy was written like a report when you see the following:

Where the case stands now

Hind collected three real cases from recent weeks in which coordinators hesitated. For each she asked: does the current policy answer it? In all three the answer was no. The fault lay not with the staff or with their not reading. It lay in the policy never having been designed to answer.

“Collect three cases where your colleagues recently hesitated, and ask of each: does our policy answer it?”

What is an operating policy?

By operating policy we mean **a decision tool embedded in the daily flow of work.** It does not explain a topic; it settles a specific decision at a specific moment. That changes how it is designed.

A good operating policy has six parts. If one is missing, it becomes a general text that fits everything and settles nothing. We give each part its own section in this article, but for now it is enough to see them together.

These are the six parts:

Notice that each part answers a question the employee asks in front of the customer. The decision says: what is asked of me? The owner says: am I the one to decide? The inputs say: what do I need to know? The constraints say: how far can I go? The consequence says: what if I step outside? And the moment of appearance says: where do I find all this when I am in a hurry?

Where the case stands now

Hind drew a table of six rows and wrote beside each what the urgent-orders policy contained. The decision: unspecified. The owner: absent. The inputs: nothing. The constraints: nothing. The consequence: nothing. The moment of appearance: a file in a folder. Six empty boxes in a nine-page document.

“Draw the same table for a policy in your organisation and mark each part: present and clear, present but vague, or absent.”

Step one: name the decision

The problem this step solves is that many policies talk about a topic rather than a decision. Theirs is urgent orders, which tells the employee nothing. The decision is the question the work puts to them every day.

To name the decision, go back to the questions that recur on people's desks. Ask the coordinators: what are the questions on which you most often have to phone your manager? You will find that the important ones are few, usually three or four. Write each as a decision beginning with should or when, and every question gets a clear title.

Then choose just one decision to start. Do not try to rewrite the whole policy at once; you will drown in detail. Start with the most frequent decision, or the one that costs most when someone errs, and build a small, complete policy for it. If it works it becomes the model for the rest.

Test your phrasing of the decision with these questions:

Where the case stands now

Hind asked the five coordinators, and they agreed that one question troubles them most: should we accept a customer's request to move a shipment forward? The other questions, such as address changes and added items, are less frequent. So Hind chose this decision alone to start from.

“Ask three colleagues for the question on which they most often have to call their manager, and write it as should...?”

Step two: say who owns the decision

Once Hind had named the decision, a new problem appeared: who decides? At present Omar decides because he is there, and on days he is not, another coordinator decides in a different way. A decision with no owner falls on whoever meets the customer first, who is often the least empowered and the most afraid.

The remedy is for the policy to name the role that holds the decision, not the person. We write the shift shipping coordinator, not Omar, because people change and roles remain. Alongside, we give a deputy for when they are away, a ceiling on their authority, and the point at which the decision goes up.

Here is an important point: the decision owner should be the person closest to the information, not the highest in the hierarchy. If every decision goes up to the manager, the manager becomes a bottleneck and customers wait. The working rule: push the decision down to the lowest level that holds the information, and raise only what exceeds its ceiling.

This is how Hind set the decision levels for urgent orders:

Where the case stands now

When a request to move a date reaches the coordinator now, he knows he holds the decision within clear limits and must raise it to the supervisor when he exceeds them. The phrase I will ask my manager disappeared from the calls, replaced by a decision in minutes.

“Set three levels for the decision you named, each with a ceiling and a deputy.”

Step three: specify the inputs

The problem here is that a good decision needs information, and under pressure the employee does not know what to ask or where to look. So they decide on what they remember, as Omar did when he relied on the customer's importance alone and did not notice the effect on other shipments.

The remedy is for the policy to name the inputs required before the decision and give each one its source. Keep to four at most, since every extra input slows the decision. Choose the inputs whose absence would make people err, and ignore the rest.

These are the inputs to Hind's date-change decision, with the source of each:

A common mistake is for the policy to demand inputs that cannot be obtained in minutes. If an input needs a message to another department, nobody will use it under pressure. Always ask yourself: can the coordinator gather these four inputs in under two minutes? If not, redesign the source, not the policy.

Where the case stands now

Hind sat with the technology team and found that all four pieces of information already existed in the systems, but on four different screens. They agreed to gather them in one small screen shown beside the request. When Omar tried it he said: had I had this screen on the day of the big request, I would have refused.

“List only four inputs your decision needs, and write beside each: where it comes from and how long it takes to get.”

Step four: set constraints in numbers

Now the coordinator knows the decision, who owns it and what to ask. What remains is the limit: how far may I go? General policies speak of reasonable limits, a phrase no two people agree on. What Omar finds reasonable another may find excessive.

The remedy is to write constraints as numbers and conditions that can be checked. A good constraint says: the request is not accepted if it delays more than one shipment, or if the extra transport cost exceeds a set amount. A stranger can read the constraint and the coordinator's decision and say: complied or did not.

Do not fear numbers. They may change after two months when you see how things go, and that is acceptable. A stated number that can be revised is better than a vague phrase that never moves. What matters is that the limit is not in anyone's head but written where everyone sees it.

Test your constraints with these rules:

Where the case stands now

Hind wrote three constraints: do not delay more than two shipments without the supervisor's approval; do not exceed an extra-cost ceiling set by customer class; and accept no date-advance request after the daily schedule closes at two in the afternoon. Beside each she wrote a one-line reason.

“Write one constraint for your decision as a number or condition, and try it on two past cases: would it have prevented the error or allowed the right call?”

Step five: define the consequence of override

Life does not lack exceptions. A day will come when a customer deserves to have a constraint crossed. The problem is that policies that do not mention exceptions get broken in secret, and the organisation loses control and information together.

The remedy is for the policy to say plainly what happens when someone steps outside the rule. Who may approve the exception? What is written in the record? When is it reviewed? This makes the exception a legitimate, visible decision and not a hidden breach. Everyone learns from it: if an exception recurs three times, that signals the constraint itself needs review.

The consequence is not necessarily a punishment. It is simply the price of departure: a higher approval, a written record, a notice to those affected. The aim is that departing from the rule is slightly harder than following it, not impossible.

This is the override rule Hind wrote:

Where the case stands now

Two weeks later the same major customer called with a similar request. The coordinator saw it exceeded the constraint and raised it to Hind, who approved because the customer was strategic and asked that the two affected customers be told. The exception and its cost were logged, and no one was surprised.

“Ask: what was the last exception on your decision in your organisation? How did you learn of it? And who approved it?”

Step six: show the policy at the moment of decision

Here is the last problem, and the most important: where is the policy when the employee needs it? Everything Hind has done so far is useless if it stays in a file. The hurried employee does not open a folder; they look at the screen in front of them.

The remedy is for the policy to appear at the moment of decision itself, in the place the employee looks. It might be a small card on the urgent-request screen carrying the decision, the three constraints and the inputs; or an approval form that gathers the questions; or a six-step decision tree on the wall at the shift desk. What matters is that it is in the work, not beside it.

When the policy appears at the moment of decision, its nature changes. It is no longer something kept because it is required but something used because it is useful. The employee opens it when needed because it saves them a call and hesitation, protects them from blame, and makes their decision defensible.

Make your policy appear at the moment of decision with these steps:

Where the case stands now

Hind turned the policy into a card on the urgent-order screen, showing whenever a date-advance request is opened. She tried it for a month. At its end she reviewed the log and found that calls to the supervisor had halved and that shipments delayed by urgent requests had fallen. Most telling, Omar now said to the customer: let me see what the schedule allows, instead of I will ask my manager.

“Design a one-page card for your decision, put it where the employee looks, and try it for two weeks.”

How do you know the policy works?

Do not rely on impressions. Three questions reveal whether your policy is a real decision tool. First: if you ask a new employee the decision question, can they find the answer unaided in two minutes? Second: if you show a stranger three past cases together with the policy, do they reach the same decision that was taken? Third: how often did people go back to the manager rather than the policy this month?

If the answers are poor, do not blame the people. Go back to the six parts and look for the box that is incomplete. And review the policy whenever the work changes, not once a year at audit time. An operating policy is a living thing that learns from its exceptions.

“The policy surfaces at the moment of decision, not in an annual audit. It is used because it is useful, not filed because it is required.”

“Go back to the question you wrote at the start. Does your policy answer it now? And which of its six parts is the weakest?”

What you carry with you

Hind's story says a policy is not a text we write and then store, but a decision we design and then place before the person who needs it. A policy that names the decision, fixes its owner, inputs, constraints and override consequence, and appears at the moment of work is one people return to without being obliged.

This is what you carry with you:

Our invitation is practical: this week pick one recurring decision in your organisation, fill in the six parts for it on a single page, then place it before the person who makes the decision and try it for two weeks. And if you want to design operating policies with experts guiding you on your real cases, explore RAISO's policy pathway.