Change approvals without email ping-pong

On Monday morning the change manager’s inbox holds dozens of messages. Some are requests for outage approval, some are replies to them, others are forwarded questions along the lines of “could you take a look?”. Some service owners replied “OK”, some did not reply at all, and one replied to only half the recipients. The maintenance window is on Thursday, and nobody knows for certain which changes are approved.

For engineers, this means uncertainty about whether they can go ahead. For service owners, it means a stream of messages without context: they do not know exactly what will happen or what it means for their service. And if something goes wrong later, working out who approved what, and on the basis of which information, becomes detective work.

Why email is the wrong tool for approvals

Email is fine for communication. It is a poor tool for decisions that need to be traceable.

• No overview. Nobody can see in one place what is waiting on whom, and for how long.
• No context. The approver gets a description of the work, but not which services will be down.
• Unclear recipient. Who should approve the outage: the application owner, the team lead, or someone from the business?
• “OK” is not a decision. An email approval has no clear link to a specific version of the change, and rejections are often simply missing. The reply never comes.
• Different processes, different paths. Changes are approved one way, requests another, patching a third.

A better way to run approvals

A sound approval process answers three questions: who decides, on what basis, and what happens if they do not. We recommend:

1. One place for every approval request, whichever process it comes from.
2. Consent comes from whoever is affected: the owner of the impacted service, not whoever happened to be copied on the email.
3. The approver sees the impact. They know which services will be unavailable or degraded, and when.
4. A rejection has a reason. The requester knows what to change without chasing anyone.
5. Proportionate rigour. Routine changes do not need a CAB; risky ones do.

How Eywo Stratum handles it

Eywo Stratum brings every approval request into a single “Awaiting approval” queue. It holds outages from changes, service requests, patch agreements and price list proposals. One rule determines who the owner is for all of them; if a service has no owner, the change manager decides.

Before a change is submitted, Stratum calculates its impact: which services and applications will be unavailable or degraded. The outage is then approved by the owner of the affected service, with full knowledge of what the work involves. A change can only be scheduled inside a maintenance window, outside change freezes and without clashing with other changes.

The level of scrutiny is set by change models:

• standard pre-approved changes for recurring routine work,
• normal changes approved by the service owner, the change manager and, where needed, the CAB,
• emergency changes for situations that cannot wait.

Every rejection comes with a reason, so the requester knows what to fix. Each decision is written to the audit trail, and notifications go out by email or to Slack according to rules. Email becomes a way to alert people, not the place where decisions are made.

Conclusion

Change approval does not have to be an endless exchange of messages. When every request sits in one place, the approver can see the impact and every rejection has a reason, decisions are made faster and with more confidence. Engineers know where they stand, and service owners can be sure nothing happens to their service without their knowledge.

The single approval queue, change models, impact calculation and outage approval by service owners are part of the Standard edition.