Translating Tenant SLAs into Building Priorities

Why this episode matters

In this episode of Built, Wired, and Secured, Alex Morgan and Michael Harrington break down a problem that shows up in commercial buildings all the time: tenants ask for uptime, resilience, and fast connectivity, but those expectations rarely get translated into the physical and operational realities of the building. That mismatch creates risk. Owners may spend heavily on redundancy and still miss the actual point of failure. Tenants may assume someone else owns failover, backup communications, or testing. Vendors may meet the letter of a contract while the building still cannot support continuity when something breaks.

The conversation starts with a sharp example. A building owner invested millions in redundancy, including separate backups, new fiber, and a private generator, yet one misrouted riser cable and one misconfigured handoff still caused a major outage. The money was real, the infrastructure looked resilient on paper, and the tenant still went down. That is the core lesson of the episode: assumptions fail when service expectations are not mapped to actual infrastructure, operational ownership, and tested recovery paths.

The language gap between tenant SLAs and building operations

A central idea in the episode is that tenant SLAs and building service levels live in different languages. Tenants think in terms of outcomes. They care about whether phones work, whether EMR access stays available, whether access control remains functional, and whether point of sale or emergency monitoring can keep running. Owners and facilities teams often think in terms of building systems, vendors, power, risers, carriers, and maintenance obligations. Contracts often separate those two worlds instead of connecting them.

That gap creates the questions that usually surface during or after an outage:

• Who owns backup internet?
• Who is responsible for testing failover?
• Which systems receive priority power?
• Where does the carrier path actually enter the building?
• Which handoff, closet, riser, or upstream utility path can still take everything down?

As Michael explains, the first operational question is simple: what breaks if this goes down? If a team cannot answer that clearly, it cannot prioritize spending or define accountability in a way that holds up under pressure.

A practical framework for inventory and prioritization

The episode lays out a straightforward, repeatable process for turning vague service expectations into prioritized building decisions.

• Step one: interview tenants and document the services they rely on, from receptionist Wi Fi to emergency monitoring.
• Step two: assign each service a business impact score using practical factors such as downtime cost, safety risk, and tenant satisfaction.
• Step three: map each service to the infrastructure and vendors that support it, including power feeds, riser pathways, carrier handoffs, edge equipment, and responsibility by party.
• Step four: score both impact and likelihood so the final priorities reflect actual business risk instead of general fear or broad assumptions.

This is where hidden single points of failure become visible. A building may appear to have carrier diversity, but if both carriers enter on the same rooftop pathway, the diversity is largely cosmetic. The same is true for power. Two circuits that trace back to one transformer may look redundant until a failure proves otherwise. The value of the mapping exercise is that it connects money to risk in a way owners, tenants, and vendors can all understand.

What good prioritization looks like in practice

One of the most useful parts of the discussion is the medical tenant example. The tenant rated EMR access as completely critical. The owner initially leaned toward a large buildingwide investment with separate generators and redundant UPS lines. After mapping the service properly, the team found that the EMR servers and telecom handoff shared one outside utility path. That upstream exposure mattered more than duplicating everything inside the building.

The better fix was more focused:

• Harden the exposed utility path
• Coordinate a scheduled proof test with the carrier and tenant IT
• Provide a simple local failover for the most critical sessions

The result addressed the real weakness at a lower cost than broad generator redundancy. The point is not that redundancy is bad. The point is that untargeted redundancy can be expensive without solving the most likely failure mode.

The three levers owners can actually use

Michael organizes the decision making around three practical levers: zoning, diversification, and targeted redundancy.

• Zoning limits blast radius by segmenting power and network so one failure does not affect the entire building.
• Diversification means true physical separation for carriers and pathways, not just multiple logos on a contract.
• Targeted redundancy applies stronger resilience only where the business impact score justifies it.

The discussion around backup communications is especially useful. A second carrier with true path diversity may be the right answer for the highest impact tenants. For other tenants or service classes, cellular or SD WAN failover may deliver enough resilience at a fraction of the cost. That is a more mature way to prioritize budget: not everything gets mirrored, but the most important services get the protection they actually need.

Why operations matter as much as design

The episode makes another point that often gets missed in capital planning: resilience is not just a design decision. It is an operations discipline. You can build the right systems and still fail in a crisis if nobody owns the process or validates the assumptions.

To operationalize commitments, the episode recommends:

• Create runbooks that connect each tenant critical service to building ownership, vendor responsibilities, and tenant IT roles
• Schedule and document regular tests for carrier failover, generator startup, and application continuity
• Require vendors to provide proof of path diversity
• Include acceptance criteria in statements of work and lease appendices
• Maintain a living diagram and a change log so documentation stays usable during real incidents

This matters because redundancy adds complexity. If a team does not maintain that complexity, it creates more opportunities for failure. Testing is what separates theoretical resilience from operational resilience.

The immediate checklist from the episode

The episode closes with a concise checklist listeners can use right away:

• Inventory tenant critical services and map them to infrastructure components
• Score business impact and likelihood to prioritize spending
• Verify real physical diversity for power and carriers instead of assuming it exists
• Use targeted redundancy where business impact justifies the cost
• Formalize responsibilities through runbooks, vendor statements of work, and regular test plans

Listeners are also directed to the Built, Wired, and Secured website for a one page SLA to infrastructure worksheet that can be used with a tenant or pilot floor.

Final takeaway

This episode is not really about chasing perfect uptime language. It is about turning tenant expectations into operationally defensible building decisions. The best building priorities come from tracing each critical tenant service back to the infrastructure, pathways, vendors, and people that keep it alive. When that translation is done well, owners spend more intelligently, tenants get clearer expectations, and outages create fewer surprises, fewer disputes, and less finger pointing.

Tenant SLAs do not protect a building by themselves

Property owners and facilities teams hear the same phrases all the time: 100 percent uptime, fast internet, resilient communications, no interruption to critical operations. Those demands usually show up in lease conversations, service expectations, or vendor contracts. The problem is that those phrases are often treated like finished answers when they are really just starting points.

In this episode of Built, Wired, and Secured, Alex Morgan and Michael Harrington explain what happens when tenant expectations are not translated into building priorities. The result is usually expensive confusion. Owners spend on redundancy that looks impressive but does not protect the real weak point. Tenants assume someone else owns continuity. Vendors deliver part of the stack but not the outcome. Then one outage exposes the gap.

The opening example says it plainly. An owner spent millions on redundancy, separate backups, new fiber, and a private generator. Even with all that investment, a single misrouted riser cable and one misconfigured handoff still brought the tenant down. That is the kind of failure that damages trust because it makes everyone feel misled. The infrastructure looked serious. The promises sounded serious. The continuity was still fragile.

The core issue is translation

The most useful idea in the episode is also the simplest: tenant SLAs and building service levels are not the same thing. Tenants speak in business outcomes. Owners and building teams work with infrastructure, pathways, power, closets, carriers, and vendor scopes. Those two worlds often live in separate documents and separate conversations.

That disconnect creates practical confusion:

• Who owns backup internet for a tenant critical service?
• Who is responsible for testing failover?
• Which systems receive priority power when capacity is constrained?
• Is the apparent carrier diversity actually physically diverse?
• Does anyone know where the single point of failure really is?

When nobody has translated the tenant outcome into a mapped building dependency, outages become argument generators. The tenant expected continuity. The owner expected the vendor handoff to cover it. The carrier assumed its scope ended at a certain point. Tenant IT assumed the building path was redundant. Everybody had a partial assumption, and nobody had an operationally complete answer.

Start with the service, not the hardware

Michael frames the first operational question well: what breaks if this goes down? That is the right starting point because it forces teams to define the service before they jump into technology purchases.

Instead of saying a tenant needs reliable connectivity, define what that means in practice. Is the critical dependency VOIP? Point of sale? Clinical devices? Access control? Emergency monitoring? A receptionist Wi Fi network that shapes first impressions? An EMR workflow that cannot tolerate interruption? Each of those services has a different business consequence, a different recovery expectation, and a different infrastructure chain behind it.

This is where many building planning efforts go sideways. Teams start with a technology answer such as another UPS, another circuit, another carrier, or a broader generator plan. Those tools may be useful, but until the service is mapped, the investment may not address the real failure path.

A repeatable framework that building teams can actually use

The episode outlines a practical framework that owners, facilities teams, and tenant technology stakeholders can use without turning the process into a consulting exercise that never ends.

First, interview tenants and capture the services they depend on. That list should include obvious critical functions and the less obvious ones that still create operational pain when they fail.

Second, assign a business impact score to each service. The episode suggests a short scale and practical factors such as downtime cost, safety risk, and tenant satisfaction. The point is not mathematical perfection. The point is to create a shared ranking that moves the discussion out of vague language.

Third, map each service to the infrastructure and vendors that support it. That includes power feeds, riser pathways, carrier handoffs, edge equipment, utility dependencies, and who owns what. This is where hidden single points of failure usually appear.

Finally, score likelihood as well as impact. A highly critical service with a low probability issue may deserve a different response than a moderately critical service sitting on an obvious weak point that has never been tested. Good prioritization requires both.

Why mapping matters more than assumptions

Two examples in the episode stand out because they show how easy it is to confuse appearances with resilience.

The first is carrier diversity. Two carriers can look like a strong answer until someone traces their paths and realizes both ride the same rooftop pathway or depend on the same upstream node. That is not meaningful diversity.

The second is power redundancy. Two circuits may appear separate until they trace back to the same transformer. On paper, the system looks protected. In practice, the building is still exposed to one upstream event.

These are exactly the kinds of conditions that cause owners to overspend and still miss the real problem. Mapping turns assumptions into evidence. It gives teams a way to verify whether the resilience they think they bought is actually there.

The medical tenant example is the real budgeting lesson

The episode gives a strong example involving a medical tenant that rated EMR access as completely critical. The owner was prepared to invest in separate generators and buildingwide redundant UPS lines. After the services were mapped, the team discovered that the EMR servers and telecom handoff shared a single utility path outside the building.

That changed the decision. Instead of treating the entire building like it needed maximum redundancy everywhere, the better move was to harden the exposed path, coordinate a scheduled proof test with the carrier and tenant IT, and create a simple local failover for the most critical sessions.

That is the budgeting lesson owners need to hear. The right answer is not always bigger. Sometimes the right answer is narrower, more verified, and much cheaper. Smart resilience planning is not about building the most infrastructure. It is about protecting the business function that actually matters.

The three levers that make planning practical

Michael groups the building side of the decision into three levers: zoning, diversification, and targeted redundancy.

Zoning reduces blast radius. If a failure can be contained to part of a building instead of affecting everyone, the continuity posture improves immediately. This is one of the most practical tools owners have because it can shape both electrical and network design.

Diversification is about real path separation. Different providers are not enough if they share the same physical exposure. Separate trenches or pathways matter because they create independent survivability.

Targeted redundancy is where budget discipline shows up. The highest impact services may justify full redundancy. Others may be better served by pragmatic fallbacks. The episode points to cellular or SD WAN failover as lower cost backup communication options that can provide meaningful resilience for services that do not warrant the highest spend.

That is a mature capital planning model. It avoids the trap of either underbuilding or trying to mirror everything. Instead, it aligns resilience to business impact.

Operations decide whether the design holds up

One of the strongest parts of the episode is the reminder that infrastructure decisions are only half the job. If teams do not operationalize the commitments, the building is still vulnerable.

The recommendation is direct:

• Create runbooks that tie each tenant critical service to owner, vendor, and tenant IT responsibilities
• Schedule regular testing for carrier failover, generator startup, and application continuity
• Require proof of path diversity from vendors
• Build service acceptance criteria into statements of work and lease appendices
• Maintain a living diagram and a change log so documentation stays current

This matters because redundancy increases complexity. If the building team does not maintain that complexity, the resilience strategy turns into its own risk. Testing is not a nice extra. It is the only way to confirm that the assumptions still hold after moves, adds, changes, vendor updates, and infrastructure drift.

What owners and facilities teams should do next

If you manage a building, a portfolio, or tenant technology relationships, this episode offers a practical starting point. Pick one floor, one tenant class, or one known critical service. Build the inventory. Score impact. Map dependencies. Verify physical diversity. Document ownership. Test failover. Then adjust your capital and operations plan based on evidence.

That approach is far more effective than reacting to broad demands for uptime with broad spending. It produces better vendor decisions, clearer contract language, and a stronger continuity posture for the tenants who rely on the building every day.

If you want a clear framework for turning service expectations into building decisions, this episode is worth your time. Listen to Translating Tenant SLAs into Building Priorities on Built, Wired, and Secured, then use the worksheet mentioned in the episode notes to run the exercise with a tenant or pilot floor.