The One-Page Facility Fact Sheet Every Manager Should Own

By Jared Mastroianni
Chief Operating Officer, modSTORAGE
CEO and Co-Founder, Facily.ai

Method and evidence boundary: This is an authored facility-identity control method, not legal, safety, accessibility, postal, mapping, marketing, security, employment, or compliance advice. Every facility, company, person, address, phone number, URL, identifier, hour, source, and result in the examples is fictional. Operators must use approved current sources and qualified owners for real facility facts. Never publish internal contacts, credentials, instructions, access details, or sensitive location data merely because a field exists in a template.

A facility manager should be able to answer a basic question quickly: what is this place, right now?

The answer is harder than it looks.

A website may use one name. A sign may use another. A postal file may normalize the address differently. The facility office may open at 9:00 a.m. while the front gate opens earlier. A holiday exception may supersede the regular schedule. A call-tracking number may appear publicly while the operating team uses a different escalation number. A location may be open to current tenants but not staffed for walk-in service.

None of those facts belongs in a manager’s memory alone.

The one-page facility fact sheet is a current operating record that separates identity, public information, internal routing, hours, lifecycle, and provenance. It is not a brochure and it is not a data dump. It is the smallest record from which a manager can explain a facility without guessing.

Start with a stable facility identity

Names, addresses, and phone numbers change. A stable internal facility ID should not.

The first line of the sheet should contain:

• facility_id — a durable portfolio identifier;
• fact_sheet_version — the exact record version;
• effective_at — when the version became authoritative for its stated scope;
• reviewed_at — when a named owner last checked it;
• next_review_at — the scheduled review point;
• current_state — current, change_pending, conflict_open, temporarily_closed, retired, or another approved state.

The facility ID is a correlation key, not an ownership claim. It should connect work orders, content, local listings, maps, analytics, access systems, customer messages, vendor records, and financial workflows without forcing those systems to share one mutable name.

The version matters because a fact sheet without a version cannot be cited. “Use the facility fact sheet” is ambiguous if three copies exist and no one knows which is current.

Block 1: identity names

Keep different kinds of names in different fields.

• Customer-facing name: the approved name used for current public-facing operations.
• Sign name: the name visible at the physical location, with a dated source.
• Internal portfolio name: the operating label used in internal systems.
• Platform display name: the exact name approved for a particular external platform.
• Legal-entity name: include only when a qualified source owner approves its operational use.
• Prior or alias name: historical reference, never silently presented as current.

Do not infer a legal owner, operator, manager, franchise, provider, or brand relationship from a shared name, email domain, website link, map pin, or software record.

Current Google Business Profile guidelines instruct businesses to represent their real-world name consistently and to place address, hours, and categories in their appropriate fields rather than stuffing them into the name. Those are mutable Google-product rules, not a universal identity standard. The useful operating lesson is to store a plain current name with its source and keep marketing language elsewhere.

Block 2: physical and postal location

One address string is not enough.

Record:

• address line 1;
• address line 2 where applicable;
• city or locality;
• state or region;
• postal code;
• country code;
• validated mailing format and validation date;
• public display address;
• map-pin coordinates, precision, source, and review date;
• customer-facing arrival note, if approved;
• entrance or office-location note, if approved;
• address-conflict state and owner.

The physical operating location, mailing address, legal address, map pin, parcel, and emergency-service location may be related. They are not automatically the same record.

The October 2024 edition of USPS Publication 28 describes complete, standardized U.S. mailing-address elements and address-list maintenance. Its scope is postal addressing. A standardized mailing address does not prove who owns a property, where a customer should enter, whether a map pin is accurate, or whether a business is operating there.

The current Schema.org PostalAddress vocabulary similarly exposes separate address components. That can help a website mirror an approved fact record, but vocabulary fields do not validate the address or authorize its publication.

Block 3: contact channels

For each contact channel, record both the value and its purpose.

Public fields may include, when approved:

• main customer phone;
• public email or contact URL;
• canonical facility webpage;
• approved rental or account-support route;
• accessibility contact route;
• after-hours customer-support route.

Internal fields may include:

• responsible facility role;
• regional escalation queue;
• vendor-routing queue;
• data-correction owner;
• outage or incident route.

Do not publish a personal number, private email, security contact, emergency instruction, employee name, credential, alarm detail, access-control topology, or vendor escalation simply because it helps internally.

A phone number also needs lifecycle state: current, forwarded, migration_pending, retired, unverified, or conflict_open. A call that rings does not prove it reaches the intended facility or that the response is correct.

Google’s current guidelines state that a listed phone should connect to the actual business and remain under the business’s direct control. That is a platform-specific rule. The broader control is to test the customer route, record the result and time, and keep technical connection separate from confirmed operational handling.

Block 4: hours without ambiguity

“Hours” is not one field.

Self-storage operations may need to distinguish:

• office hours;
• gate-access hours;
• phone-support hours;
• rental-service hours;
• appointment-only windows;
• vendor or delivery windows;
• temporary or seasonal changes;
• holiday exceptions;
• closures and reopening times.

Google’s current business guidelines specifically say storage facilities should use office hours, or otherwise front-gate hours, for the primary Business Profile hours. That does not mean office and gate hours are interchangeable inside the operating record. The fact sheet should show both and label which schedule each external surface is intended to receive.

Store a named time zone, not only an offset. The IANA Time Zone Database is periodically updated when political bodies change boundaries, offsets, or daylight-saving rules. Its current page lists release 2026c from July 8, 2026. A time-zone identifier helps software calculate local time, but it does not prove the facility’s schedule is current.

For every hours set, preserve:

• schedule type;
• days and local open/close times;
• time-zone identifier;
• effective and end dates;
• special-hours overlay;
• source owner;
• last verification;
• next review;
• public or internal classification.

The current Schema.org OpeningHoursSpecification vocabulary provides fields for days, opening and closing times, and valid-from or valid-through dates. It is a representation vocabulary, not a source of truth. Structured markup should be generated from the approved sheet, not edited as an independent schedule.

Block 5: lifecycle and operating state

A facility can be physically present while its operating state changes.

Use an approved vocabulary such as:

• pre_opening;
• open;
• office_temporarily_closed;
• access_limited;
• temporarily_closed;
• transition_pending;
• closing;
• closed;
• sold_or_transferred_unclassified;
• unknown.

The labels must be defined by the responsible owners. Do not infer a sale, management relationship, legal closure, operational control, or customer-access consequence from a listing change or a website disappearing.

Lifecycle state should include:

• observed fact;
• effective time if known;
• source and authority;
• customer-facing consequence approved for communication;
• open dependencies;
• next verification time;
• responsible owner.

“Sold or transferred unclassified” is deliberately cautious. It records that a transition may exist without claiming its legal form or operating relationship.

Block 6: public claims and operational features

A fact sheet should list only features that have an approved current source.

Examples might include:

• unit types;
• customer-access method;
• office or gate presence;
• climate-related wording;
• vehicle-storage availability;
• delivery acceptance;
• security or monitoring language;
• accessibility features;
• payment methods;
• insurance or protection-plan language.

Each feature needs a state: verified_current, verified_with_limitations, change_pending, not_offered, unknown, or do_not_publish.

Do not copy features across facilities. Do not promote a vendor capability into facility availability. Do not turn a technical component into a safety guarantee. Do not describe a feature as accessible, climate controlled, secure, monitored, available, included, or approved without the qualified source and exact permitted wording.

Schema.org’s current SelfStorage type offers a machine-readable vocabulary for a self-storage facility and inherited place or local-business properties. Its page identifies itself as the development version. Markup can mirror an evidence-cleared facility record; it does not prove ownership, profile eligibility, search inclusion, ranking, or rich-result display.

Block 7: source and change control

Every public or consequential field should answer six questions:

1. What is the exact value?
2. Which source supplied it?
3. Who has authority over that source?
4. When was it observed and when did it become effective?
5. What conflicts or limitations remain?
6. Who owns the next review or correction?

The pinned W3C PROV-O Recommendation defines general concepts for entities, activities, agents, generation, use, derivation, attribution, association, and delegation. Those concepts can link a facility fact to a source and update activity. Provenance does not prove the fact true or the source authorized. It makes the claim chain inspectable.

When two sources disagree, do not choose the newest automatically. The official facility page may lag an approved temporary closure. A listing may contain a pending change. A manager may know a fact but lack publication authority. Resolve the conflict through the source-owner map and preserve the prior value, proposed value, reason, evidence, decision, effective time, and rollback.

Block 8: destination synchronization

The fact sheet is upstream of many destinations. It should record which ones received which version.

Possible destinations include:

• facility website;
• portfolio location page;
• structured data;
• customer messaging templates;
• map or business profiles;
• rental platform;
• call routing;
• internal directory;
• vendor work-order system;
• access or building systems;
• emergency or continuity documentation.

For each destination, track:

• source fact-sheet version;
• intended fields;
• adapter or manual workflow;
• submission or change time;
• sender or operator identity;
• receipt state;
• accepted or review state;
• applied state;
• public readback state;
• current discrepancy;
• rollback action.

Submission is not acceptance. Acceptance is not application. Application is not public readback. Public readback is not search indexing or ranking.

What AI can safely do

AI can help maintain the sheet when its contribution remains visible. It may:

• extract candidate facts from approved sources;
• compare the current sheet with destination readbacks;
• flag stale, missing, or conflicting values;
• normalize a draft address while preserving the source string;
• calculate candidate holiday overlays from an approved schedule;
• draft a correction packet;
• identify destinations still carrying an older version;
• explain a discrepancy in plain language.

AI should not:

• invent a facility relationship;
• infer a feature from another location;
• decide which source has authority;
• publish a corrected address, phone, or hours value;
• classify a legal or operating transition;
• turn an unknown into a current fact;
• expose an internal contact or sensitive operating detail;
• treat a successful API response as a verified public result.

Keep AI output labeled candidate until a qualified source owner admits it into the fact sheet.

A fictional one-page example

Fictional Alder Annex uses FAC-FICTION-ALDER-01 as its stable identity. Version 18 is current.

The customer-facing name and sign name agree. The USPS-formatted mailing address and the public display address contain the same core elements, but the arrival note identifies a different customer entrance. The office schedule is Monday through Saturday; the gate schedule is broader. Both use America/Denver, and a date-bounded holiday overlay is attached.

The main phone passed a technical connection check. Operational handling is awaiting a separate sample, so its state is connected_handling_unverified. The website and one listing display version 18. A second listing still displays version 17 and has an open correction record. One advertised feature remains unknown because the source owner has not approved the wording.

The sheet does not resolve that uncertainty by guessing. It tells the manager what is known, what is not, where the discrepancy exists, and who owns the next action.

No part of the example proves a real facility, product, listing, profile, feature, or operating result.

The manager’s five-minute test

Choose one facility and open the current fact sheet.

In five minutes, a manager should be able to answer:

1. Which facility identity and version am I using?
2. What customer-facing name, address, phone, website, office hours, and gate hours are current?
3. Which fields are public, internal, unknown, conflicting, or held?
4. Which source and owner support each consequential field?
5. Which destinations still disagree, and who owns each correction?

If the answer depends on memory, an old email, a search result, or “what the other site uses,” the facility does not yet own its identity.

Use the companion one-page facility fact-sheet template, 10-row fictional facility identity register, and 36-case readiness suite to create the first governed version. The facility fact-sheet anatomy provides a visual walkthrough. Keep the sheet compact enough to use and structured enough to verify. The value is not the page count. The value is that every important fact has a source, a state, and an owner.

Sources

The package-level source register records the date, exact claim supported, and limitations for every official source used below.

• Guidelines for representing your business on Google, Google Business Profile Help, current mutable page checked August 22, 2026.
• Publication 28: Postal Addressing Standards, United States Postal Service, October 2024 edition.
• Time Zones, IANA, current page checked August 22, 2026; latest listed release 2026c from July 8, 2026.
• SelfStorage, Schema.org current development vocabulary checked August 22, 2026.
• PostalAddress, Schema.org current development vocabulary checked August 22, 2026.
• OpeningHoursSpecification, Schema.org current development vocabulary checked August 22, 2026.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.