Build the Emergency Plan in Microsoft 365: SharePoint, Teams, and Lists

Direct answer. Put the commercial client’s emergency response plan inside the Microsoft 365 tenant they already run. The restorer builds and maintains it as a service; the client keeps ownership of their own system. SharePoint holds the document set, Microsoft Lists holds the live registers, Teams holds the incident channel, and Forms (or a short intake list) captures loss notification — no new software for the client to buy or learn.

This is a build chapter. It assumes the walkthrough already happened and the property packet exists on paper or in your files. The job here is to assemble that packet where the facility manager, chief engineer, and after-hours desk already work.

Frame it correctly for the FM. You are not selling a portal. You are wiring their building intel into tools their IT already licenses. The Emergency Response Agreement is still the contract that puts you first on the call sheet. This chapter is how you make the property packet usable at 2 a.m.

1. SharePoint document library: the plan document set

Create one SharePoint site (or a dedicated library on an existing facilities site) for emergency response. Name it so a night engineer can find it without guessing — something like “Emergency Response — [Building Name].” One library per facility beats one giant portfolio dump.

Build folders for the document set the plan actually needs:

Facility profile — occupancy type, hours, critical areas, known water and fire history notes from the walk
Shut-off locations — labeled photos, valve tags, electrical room notes, fire-sprinkler riser context
Vendor and communication tree — who calls whom, restorer after-hours number, building contacts, specialty vendors
Service agreements — the signed Emergency Response Agreement exhibit set, certificates, rate schedule references the FM already approved
Floor plans — current plans the engineer trusts, marked with shut-offs and access paths where you walked them

Naming convention matters more than fancy metadata. Use a pattern both sides can type under stress: [Building]_[DocType]_[LocationOrVersion]_[YYYY-MM-DD]. Example shape: MainStTower_Shutoff_MechBasement_2026-10-01. Keep file names boring and searchable.

Turn on version history for the library and treat it as the record of truth. When a shut-off photo is replaced, the old file stays recoverable. When legal updates the agreement PDF, the prior signed copy is still there. Do not rely on email attachments as the archive.

Pin a short “Start here” document at the library root: what each folder holds, who owns updates, and the link to the live Lists. The restorer loads the first cut after the walk. The client owns the tenant. Your role is build and maintain — not to hold the only copy on your hard drive.

2. Microsoft Lists: the live registers

Documents go stale the week someone changes a cell-phone number. Put the registers that change into Microsoft Lists so both sides can update without rewriting a PDF.

Minimum lists for a commercial facility:

Contacts — role, name, phone, email, after-hours flag, who is allowed to activate the restorer
Shut-offs — system, location description, photo link back to SharePoint, tag ID, last verified date
Equipment — critical gear that affects response (pumps, generators, BMS contacts), location, notes
Access notes — badge rules, alarm company, loading dock hours, roof access, elevator overrides, after-hours entry path

Each list item should have a last-verified date and an owner field (client role, not a person’s ego). The restorer can propose edits; the client’s named owner accepts them. That keeps the system theirs.

Views that earn their keep: “After-hours activators,” “Shut-offs not verified in 90 days,” and “Critical equipment.” Link list items to SharePoint photos instead of embedding everything in the list. Lists for the live fields; the library for the heavy files.

3. Teams: the incident channel

Create a Team (or a private channel under a facilities Team) named for the facility. Example: ERP — Main Street Tower. This is not a marketing chat. It is the place the plan links live when water is on the floor.

Pin: the SharePoint library, the Lists, the “Start here” doc, and the restorer after-hours contact card. Add people by role, not by friendship:

Client: facility manager, chief engineer, after-hours answering desk lead, security if they control access
Restorer: account lead, after-hours dispatch, and the estimator who will open the file

When a loss starts, the channel is where photos, access updates, and “we’re on site” land so the FM is not hunting text threads. When the loss closes, archive the chat trail with the job documentation practices you already use — the channel is coordination, not the claim file.

For multi-building clients, one Team with a channel per facility usually beats dozens of orphan Teams. Match whatever their IT already prefers; do not invent a second org chart inside Microsoft 365.

4. Forms or simple intake for loss notification

At first notice of loss, you need the same details every time: who is calling, address and area affected, when it started, water/fire/other, whether intrusion is active, access path, insurance contacts if known, and who can authorize emergency scope.

Build that as a Microsoft Form linked from the Teams channel and the SharePoint “Start here” page — or as a dedicated intake list with a simple form view if the client already lives in Lists. Keep fields short. The goal is a clean first record, not a claims novel.

Route submissions to the restorer dispatch mailbox and post a confirmation into the facility channel. The Form does not replace a signed work authorization. It replaces the sticky-note phase before anyone is on site. Pair it with your normal authorization and documentation sequence once the crew rolls.

5. Permissions: who owns it, who gets in, what happens when jobs change

Name a client owner. Usually the facility manager or a facilities systems admin who already manages SharePoint permissions. That person owns membership. The restorer gets guest or partner access to the library, lists, and Teams channel needed for the facility — nothing else in the tenant.

Split rights:

Client owner: full control of membership and structure
Client editors: engineers and desk staff who update contacts, access notes, and verification dates
Client readers: leadership who need to see the plan but should not rearrange it at 2 a.m.
Restorer editors: account team that maintains photos, shut-off verification, and agreement exhibits
Restorer readers: after-hours dispatch who need the packet without redesigning it

When people change jobs, the client owner removes the departed user and adds the successor the same week — not after the next loss. Put that rule in the “Start here” doc. The restorer’s quarterly review should flag stale names in the Contacts list. Guest access for the restorer should be tied to roles (dispatch, account lead), not to one technician’s personal email that vanishes when they leave your shop.

IT on the client side still owns tenant security. You work inside their rules. If their security team requires a specific external sharing pattern, use it. The plan fails if it lives in a sharing link nobody can renew.

6. Keeping it current: quarterly rhythm, client-side owner

A plan that is not reviewed is a brochure with a SharePoint URL. Run a quarterly review with the client owner:

Walk the Contacts list — phones, activators, after-hours desk
Re-verify shut-offs that moved, got tagged, or failed a test
Replace outdated floor plans and agreement exhibits
Confirm Teams membership matches current roles
Confirm the Form still routes to live mailboxes
Schedule the next review on the calendar before you leave the meeting

The restorer brings the checklist and does the file work. The client owner signs off that the registers are true. Tie the review to the commercial QBR cadence when you have an Emergency Response Agreement on the door — renewal conversations are easier when the packet is current.

Between quarters, either side can update a list item when something changes. The quarterly pass catches what daily urgency misses.

Where this stack strains

Be honest with the FM and with yourself.

Microsoft 365 only works if someone on the client side will own membership and will open Teams when it matters. If the engineer refuses anything that is not a binder on the mech-room shelf, keep a thin printed packet and still store the master in SharePoint — do not pretend the printout is the system of record.

Guest access is where deals stall. Some tenants lock external sharing hard. Budget time with their IT early; do not promise “we’ll just share a folder” on a sales call and discover a block the night of a loss.

Lists and libraries drift apart when photos are updated in one place and descriptions in another. The shut-off list must point at the current SharePoint file. Version history helps; discipline still matters.

Teams channels get noisy if every vendor is added. Keep membership tight. A channel full of spectators is not an incident channel.

Forms intake dies if the link is buried. Pin it. Test it quarterly with a fake submission.

This stack also does not replace training. People still need to know which Team, which list, and who can authorize work. The software is the shelf. The walkthrough and the named owner are the product.

If the client is a Google shop, do not force Microsoft 365. Use the same build logic in their stack. The principle is “inside the tenant they already have,” not “Microsoft or nothing.”

What you deliver as the restorer

You deliver a working facility package: library structure loaded, lists populated from the walk, Teams channel pinned, intake linked, permissions documented, and a quarterly review on the calendar. The client keeps the tenant. You maintain the packet as a service. That is how an independent shows up differently from a national coverage map — building-specific intel, already filed where the night desk works.

Questions

Do we need a new app for the client? No. Use SharePoint, Lists, Teams, and Forms inside the Microsoft 365 tenant they already have.

Is this the same as an Emergency Response Agreement? No. This is the property packet and operating shelf. The ERA is the pre-loss contract for first-call rights, rates, and authorization limits.

Who should own permissions? A named client owner — usually the FM or facilities admin — with the restorer on scoped access for the facility package only.

What if the client will not allow guest access? Work with their IT on an approved external pattern, or have a client editor maintain updates you supply. Do not leave the only current copy on the restorer’s laptop.

How often should it be reviewed? At least quarterly, with a named client owner sign-off, plus updates whenever contacts, shut-offs, or access rules change.

Learn the stack

Official Microsoft training for the tools in this build — free, from the source: