# Change approvals without email ping-pong · Stilla > A change waits for approval, the approval sits in someone’s inbox, and the maintenance window is getting close. URL: https://stilla.eywo.digital/en/blog/change-approvals-without-email/ Language: en Last updated: 2026-10-25 [← Back to the blog](https://stilla.eywo.digital/en/blog/) Change2 July 2026Updated 25 October 20263 min readEywo team # Change approvals without email ping-pong A change waits for approval, the approval sits in someone’s inbox, and the maintenance window is getting close. Here is how to move approvals out of email and into a single queue. 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 Stilla handles it Stilla 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, Stilla **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. **Stilla Standard** For organisations that want a reliable CMDB and managed ITSM processes. [Compare editions →](https://stilla.eywo.digital/en/editions/) ## More articles [Change·9 July 2026 ### Maintenance windows and freezes: when production may be touched Maintenance windows, change freezes and collisions often live in people's heads and scattered spreadsheets. Here is how to turn them into rules the system enforces for you. Standard3 min read](https://stilla.eywo.digital/en/blog/maintenance-windows-and-freezes/)[CMDB·25 October 2026 ### The virtual network in the CMDB: from port group to leaf switch Between a virtual machine and the physical network sits a layer most CMDBs do not see – virtual switches, port groups and host uplinks. Yet this is exactly where it is decided which services a network change will touch. Standard3 min read](https://stilla.eywo.digital/en/blog/virtual-network-in-the-cmdb/)[Governance·25 October 2026 ### NIS2 and DORA: what operations must be able to evidence Both regulations ask the same question – do you know which services an outage hits, who is responsible for them and what changed when? Without a reliable dependency map, the answers are assembled by hand, often under time pressure. Standard3 min read](https://stilla.eywo.digital/en/blog/nis2-dora-evidence/)