Direct answer. Before you propose any emergency-plan tool, ask the facility what they already run. Microsoft 365. Google Workspace. Spreadsheets and email. That answer decides how you build the Emergency Readiness Plan — not your favorite platform, not a demo from last week. Meet them where they already work. That is the whole doctrine.
This chapter opens the Build-Your-Own-ERP series. The rest of the series shows how to assemble the packet. This piece is the question you ask first — in discovery, not the pitch — so you do not hand a facilities team another login they will never open at 2 a.m.
The question, and when to ask it
Ask plain: What system do you already use for documents, shared folders, and day-to-day collaboration?
Ask it in discovery. Not after a vendor-portal demo. Not after you promised a branded app. Discovery is the walk, the coffee, the first meeting while you are still learning the building. The pitch comes after you know whether the plan lives in SharePoint, a Shared Drive, or a binder-plus-folder that already works.
Asked in the pitch, the question sounds like a stall. Asked in discovery, it sounds like competence. You are finding the shelf where the plan will sit — not shopping for software on their dime. An ERP that never gets opened is shelfware with your logo on it. The system question is how you avoid that before you spend an hour formatting pages.
Who actually knows
Do not ask only the facilities manager and walk away. The FM knows the building. The person who knows the file system is often someone else.
Start with the records manager, the documents person, or whoever owns the shared-drive structure. They live in the system all day. They know whether the property packet lives in a SharePoint document library, a Google Shared Drive, a departmental folder tree, or email attachments named final_v3 — and who can grant access without a ticket that dies in IT for three weeks.
The office manager is often the second stop. They know who renews licenses, who trains new hires, and which “official” tools nobody uses. Ask what people open when something breaks after hours. That answer beats the org chart.
IT comes third because they govern permissions, retention, and backup policy — not because they invent the plan’s home. Know the house style first: Microsoft tenant, Google tenant, or light stack. Then ask how to stay inside rules they already enforce. Lead with a new SaaS pitch and you inherit their approval queue. Lead with “we will build inside what you already license,” and the conversation changes.
Same shutoffs. Same contacts. Different political cost.
What each answer tells you
Microsoft 365. Build where the tenant already is. A SharePoint document library for the property packet. Teams for the people who need the plan during an event. Microsoft Lists when a living contact sheet or shutoff checklist needs more than one updater. Permissions and backups stay their IT’s problem. Your job is structure, naming, and a walkthrough that fills the library with truth.
Google Workspace. Same doctrine, different furniture. A Shared Drive for the property. Google Sheets for contacts, vendors, and shutoff maps that change. Google Docs for the narrative plan the night engineer can find without hunting email. Drive permissions and Workspace admin controls already exist. Use them. Do not invent a parallel universe a school or hospital IT will refuse to trust.
Spreadsheets and email. Do not sneer. Many buildings still run this way. Build a clean folder tree on whatever shared storage they already have. Keep master contacts in one sheet. Put the call tree and shutoff map in documents they already open. Your upgrade path is discipline — one source of truth, a named owner — not a surprise platform. If they later move to Microsoft or Google, the content travels. The habit of a single packet is what matters on night one.
Write the answer in your discovery notes before you design anything. The stack is a design constraint.
The hidden costs of one more platform
Mobile access and dashboards can be real. The costs that do not show in the demo are the ones that kill the plan.
Training. If the night engineer, GM, and regional already know Teams or Drive, that hour is free. If not, the plan waits on a calendar that never gets scheduled.
Access. New software needs accounts, guest users, and an IT ticket. During a loss, the person with the password is often not on site. Inside the client’s existing stack, you add a folder and a permission group — access is already governed.
Renewal. Every extra subscription must survive next year’s budget meeting. The ERP you built as a gift becomes a renewal argument. Plans that live in software the client already pays for do not have that fight.
Abandonment. People drop tools outside the path they walk every day. An ERP next to the same Shared Drive as the COIs and vendor list gets opened. An ERP in a portal they open twice a year gets forgotten until the pipe bursts — and then nobody remembers the password.
None of this needs a price tag to be true. The cost is time, friction, and a plan that is not findable when water is on the floor.
Where this stack strains
Honesty is the house style, so here is where building inside the client’s stack gets hard.
Microsoft and Google are collaboration systems, not restoration platforms. They will not map a riser, auto-dial your after-hours board, or replace a dedicated response product that pipes job photos, moisture logs, and dispatch into one mobile view. If the client wants that depth and already budgets for it, say so. Do not pretend a SharePoint library is a command center.
Permissions can be a mess — overshared folders, orphaned guest links, “everyone in the building” access. Build inside a broken permission model and you inherit the break. Fix access with IT before you call the packet done. Version drift is the same failure: three local copies of the contact sheet is a rumor, not a plan. One living file. One named owner.
Some verticals will not let an outside contractor structure anything in the tenant without a security review. That review is usually shorter than procuring a new vendor — but it is not zero. Ask early.
The doctrine is not “never buy specialized software.” The doctrine is “do not start there.” Start with what they run. Add a dedicated tool only when their own stack cannot carry the load they are asking for.
How the answer shapes your presentation
Once you know the stack, stop demoing software and run a working session.
Microsoft shop: open a SharePoint library structure or Teams channel outline. Show where shutoffs, contacts, photos, and the call tree will live. Speak their nouns — document library, List, channel, permission group — and prove you can leave the plan inside their house.
Google shop: same move with a Shared Drive and a Sheet. Tabs for contacts, vendors, utilities, after-hours. Show who owns the Drive and how a night engineer finds it on a phone they already use for email.
Spreadsheets and email: bring a one-page folder map and a single master sheet. Make the upgrade feel like cleanup, not conversion.
Close the same way every time: we build the Emergency Readiness Plan where your people already work. No new login. No IT approval queue for a product they did not ask for. No subscription that becomes next year’s cut. Permissions and backups stay under their own IT. You bring the walkthrough, the structure, and the discipline to keep it current.
Ask the system question first. Build second. Pitch the home you found — not the home you wished they had.
What is the first question to ask before building an Emergency Readiness Plan?
What system does the facility already run — Microsoft 365, Google Workspace, or spreadsheets and email. Ask it in discovery, before you propose any tool.
Who usually knows what system the facility actually uses?
The records manager or documents person who lives in the shared drives all day. The office manager is a strong second. IT governs permissions and backups; they are not always first to know where the working files live.
Why build the ERP inside the client’s existing stack?
No new login, no IT approval queue for another product, no shelfware subscription to renew, and permissions and backups already under their own IT.
Where does building inside Microsoft 365 or Google Workspace strain?
Those stacks are collaboration systems, not restoration command centers. Fix permissions and name an owner, or the packet still breaks. Add a dedicated tool only when the client needs dispatch-depth workflows the tenant cannot carry.
How should the stack answer change your sales presentation?
Stop demoing software they did not ask for. Show a SharePoint library, a Shared Drive and Sheet, or a cleaned folder-and-spreadsheet map — and close on a plan that lives where they already work.
Learn the stack
Whichever answer they give you, the official training is free:
- Microsoft Teams training — Microsoft Learn
- SharePoint help & learning — Microsoft Support
- Google Workspace Learning Center