Natasha French explains how service tiering evolved from a loosely discussed concept into a practical capability that shaped how her organisation designed, delivered and operated services and what they learned along the way.
Service tiering is often described as a tidy maturity step that organisations introduce once they reach a certain level. Our experience was far less linear. Tiering emerged gradually, under pressure and only became effective once we understood what problem it was really trying to solve.
This article focuses on enterprise service-level tiering in complex, client-facing, multi-supplier environments where services span business domains, shared infrastructure, and multiple delivery partners.
A follow-up article will explore consumer-level tiering in supplier-facing organisations, where services are uplifted through packaged capability models based on dependency, consumption, and business criticality.
Structure came first and exposed the gaps
Several years ago, our IT organisation moved to a tower-aligned operating model. Delivery capability was aligned to business-facing domains such as Rail, Surface, Digital, Payments, and Professional Services. Alongside these sat technology-focused towers – Network and Hosting and a shared EUC services tower.
Each business-aligned tower had service owners, product owners, and application teams. The intent was clear: improve accountability, strengthen business alignment, and enable scale.
What this structure did very effectively was expose something we had previously been able to work around: we did not have a shared, consistent understanding of what a “service” actually was.
Getting a grip on services: definition before differentiation
Before we could meaningfully talk about priority, resilience, or criticality, we had to answer some basic but uncomfortable questions:
- What do we mean by a service?
- Where does a business service end and a technical or underpinning service begin?
- How do shared services such as network, hosting and EUC support multiple business outcomes?
- Who truly owns what in a multi-tower model?
The first major step, therefore, was not tiering it was service definition
We revisited and agreed a common definition across business and technology, clarifying:
- Business-facing services
- Technical and underpinning services
- Shared services that cut across multiple towers
From there, we built service catalogues with clear tower ownership. Business services, technical services, and underpinning services were made visible- not as abstract concepts, but as real entities with named owners.
The outcome was a catalogue of over 400 services.
What visibility gave us (and what it took away)
Visibility was transformative. For the first time, we could see what existed across the organisation; ownership was explicit rather than assumed; duplication and overlap became visible; similar services delivered in different ways across towers were exposed; and dependencies on shared services were no longer implicit-they were documented.
However, this clarity also removed a layer of comfort.
Once everything was visible, it became clear that most services were being treated in broadly the same way, regardless of their purpose, impact or risk profile.
The limits of “everything is important”
With this visibility, several tensions emerged. Business-facing services and underpinning services competed for attention. Shared services underpinned multiple outcomes but were inconsistently governed. Delivery teams applied similar controls to very different services. Almost every service was described as “critical”.. but critical to what, and critical to who, was often unclear.
We had classification and visibility but no consistent, enterprise-wide way to differentiate services. Criticality was subjective, inconsistent, and often asserted rather than agreed. Decision-making under pressure highlighted the gap: we could list our services, but we could not defend which were truly critical to the organisation as a whole.
The catalyst: the data centre outage
It was at this point that a major data-centre outage occurred.
The outage cut across business services, shared infrastructure, and multiple towers simultaneously. As services failed and recovered at different speeds, it exposed gaps that had previously been hidden.
Although we had a comprehensive service catalogue, criticality had been defined inconsistently:
some services for example had resilience far beyond what business impact justified, others lacked resilience that the business would reasonably expect.
“Critical” often meant “important to this tower” , rather than “critical to the organisation.”
Shared services amplified impact, but their role in supporting high-criticality outcomes was not consistently reflected in design or investment decisions.
A necessary first step
The outage forced us to act. We introduced a lightweight, consistent method to assess criticality. The model reflected enterprise-level business impact rather than local importance, worked across towers and shared services, and aligned criticality with resilience decisions.
This initial tiering, expressed simply as Gold, Silver, and Bronze, was enough to prioritise investment and protect key outcomes.
At this stage, tiering was deliberately narrow in scope. It addressed the resilience gaps revealed by the outage, not every service design decision. It was pragmatic rather than perfect, but it gave the organisation a defensible starting point.
Growth creates a new challenge
Soon after, the volume of change accelerated. Digital delivery increased. Initiatives ran in parallel. Supplier involvement grew. Services became more tightly coupled through shared platforms and integrations.
The lightweight model remained valid, but scaling decisions became harder. Applying tiers relied heavily on individual judgement. Architects became informal gatekeepers. Similar services were designed differently depending on who was involved. The same tier triggered different expectations in different contexts.
Decisions slowed. Debates repeated.
The issue post-outage had been defining and protecting critical services. The issue post-growth was applying tiering consistently at scale. These were related but distinct challenges.
From classification to capability
To address scaling, we expanded tiering beyond resilience into a broader set of guardrails across the delivery value chain.
The tiering model evolved. Gold, Silver, and Bronze gave way to Mission Critical, Business Critical, Business Operational, and Administrative; reinforcing that tiers reflected business consequence rather than technical quality.
At the same time, we built on the original resilience-focused criteria. Tier-aligned expectations were expanded to cover service design and architectural patterns, supplier and sourcing models, integration approaches, service lifecycle decisions, and operational readiness.
Tiering was embedded directly into architecture and delivery standards, not treated as a checklist applied after the fact. New services were required to consciously choose an operating model aligned to their tier, rather than inheriting one by default.
This changed how decisions were made.
Conversations shifted from subjective importance to shared, impact-based judgement. Higher-tier services attracted deeper assurance and clearer recovery planning. Lower-tier services were still governed responsibly, but without being over-engineered.
The effect on speed was significant. In high-change, agile environments, tiering reduced ambiguity upfront. Teams could see immediately what they were working with, what was expected, and where trade-offs were acceptable. Fewer decisions were deferred, fewer assumptions went unchallenged and fewer late-stage redesigns were required.
Tiering also provided a practical way to align supplier models with business impact. Rather than assuming equivalence between vendor offerings, it allowed us to assess whether supplier capabilities genuinely matched the outcomes a service was intended to support, and to make gaps explicit early.
Operational expectations followed the same pattern. Support coverage, monitoring depth, escalation paths, and service levels aligned to tier rather than being renegotiated repeatedly. Tiering moved from something we discussed to something that actively shaped how work flowed through the organisation.
Making risk and exceptions explicit
As tiering became embedded, we learned to separate exceptions from risk.
Early on, exceptions were treated as failures, something to eliminate or defend. Over time, we learned this was unhelpful. Not all exceptions introduced risk, and treating them as such slowed delivery and blurred decision-making.
By explicitly recording what the exception was, whether it introduced risk, and what kind of risk that was, the quality of conversations improved dramatically.
Architects and delivery teams could see early where services did not fully meet tier expectations and why. When designing new services, teams could assess whether it was acceptable for a high-tier service to depend on an underpinning service with known exceptions and what mitigations were required.
As a result, risks were identified earlier, assessed more quickly, and addressed deliberately, rather than discovered late in delivery or during incidents. Over time, patterns in exception data highlighted systemic weaknesses and informed where standards or investment needed to evolve.
Tiering did not eliminate exceptions. It made them visible, understandable, and usable.. supporting better decisions rather than tighter control.
The tiering evolution
Service tiering matured in stages.
Post-outage, it focused on criticality and a small set of resilience criteria such as RPO, RTO, and availability. Post-growth, it expanded into full tier-aligned guardrails across design, supplier, integration, operational, and lifecycle decisions. Over time, it became an embedded capability: integrated into everyday decision-making, with exceptions tracked and reviewed.
This evolution reflects how tiering moved from reactive classification to a practical management capability that shaped behaviour, decisions, and investment.
Insights from the field
Looking back, service tiering only became useful once it helped people make real decisions.
It mattered most when it was anchored in business impact and used to guide everyday trade-offs such as how much resilience a service needed, what level of support was appropriate, whether a dependency was acceptable, and where investment was genuinely justified. When tiering was used this way, conversations became clearer and far less subjective.
We also learned that tiers work best as prompts for judgement rather than fixed answers. Services changed over time. Usage increased, dependencies deepened, and what had once been acceptable became critical. Allowing services to move between tiers, and revisiting those decisions periodically, kept the model relevant rather than static.
Making exceptions visible proved just as important as defining standards. Tiering did not eliminate exceptions, it made them explicit. This allowed teams to understand trade-offs early, factor constraints into new designs, and avoid discovering problems late in delivery or during incidents.
In practice, service tiering only started to matter when it helped teams move faster and make decisions with confidence. It reduced ambiguity, aligned expectations upfront, and avoided repeated debate, particularly in high-change, resource-constrained environments.
Once tiering was embedded into design, change, supplier discussions, and risk decisions, it stopped being something people debated and became something they relied on.
In Part 2 of this article, we will explore how tiering translates to consumer-facing environments, where services are packaged and prioritised by dependency and impact, and share the lessons we learned in applying these principles at scale.
Natasha French
Natasha French is a service design and transition lead and a member of the itSMF UK Service Design and Transition CoP
