By Jared Mastroianni
Chief Operating Officer, modSTORAGE
Beginner operator checklist · Updated August 22, 2026

A facility can be open for tenant access while its office is closed. A phone line can be answered while no manager is available for an in-person move-in. A kiosk can accept a rental while a truck-rental counter, retail sale, document review, or lock-cut service is unavailable.

Those are not edge cases. They are different operating controls.

When a website, directory, call script, chatbot, map profile, facility-management system, or staff handoff collapses them into one field called hours, the result may look tidy while becoming less accurate. The practical fix is to separate office hours, access hours, and service hours, then give each field a governing source, owner, effective date, and verification path.

This checklist shows how to do that without guessing which public page is correct.

Start with three definitions

Office hours describe when the facility office is scheduled to be open for in-person office activity. They do not automatically prove that every service is available, that a particular employee is present, or that tenant access begins and ends at the same time.

Access hours describe when an authorized customer is scheduled to be able to enter the property or reach a unit under the applicable access policy. They do not automatically mean the office is staffed or that assistance is immediately available.

Service hours describe when one named service is offered through one named channel. Examples include phone support, in-person move-in help, truck rental, retail sales, document verification, lock cutting, deliveries, or after-hours escalation. Service hours should be recorded per service; a single catch-all schedule usually hides important differences.

Each definition needs four qualifiers:

1. the exact facility or scope;
2. the local timezone;
3. the effective date and any holiday or exception rule; and
4. the source owner authorized to confirm or change the value.

Why a source owner matters

A public page proves what that page currently publishes. It does not, by itself, prove that the same value is configured in the access-control system, call center, property-management system, staffing schedule, lease, or another operating source.

That distinction matters when two first-party pages disagree.

In a public snapshot observed on August 22, 2026, the current modSTORAGE Ocean Township facility page listed office hours of Monday through Friday 8:00 a.m.–5:00 p.m., Saturday 8:00 a.m.–5:00 p.m., and Sunday 8:00 a.m.–4:00 p.m.; it listed access as 6:00 a.m.–10:00 p.m. daily. A separate modSTORAGE Blog directions page for the same street address listed office hours of Monday through Friday 9:00 a.m.–5:00 p.m., Saturday 9:00 a.m.–3:00 p.m., and Sunday closed, while also listing access as 6:00 a.m.–10:00 p.m. daily.

The correct conclusion is not that the newer-looking page must be right. The correct conclusion is that a conflict exists and the designated source owner must resolve it.

The same public snapshot shows why the fields cannot be merged. The current Long Island City facility page publishes 24/7 access. A separate directions article lists office hours of Monday through Saturday 8:00 a.m.–7:00 p.m. and Sunday 9:00 a.m.–4:00 p.m., alongside 24/7 access. Whatever internal verification is still required, those published schedules describe different concepts.

These examples are dated public observations, not an internal audit, a legal relationship statement, or a claim about actual staffing or access performance.

The facility-hours control record

For every facility, maintain one row for each field type and schedule segment. At minimum, capture:

The governing source may differ by field. An access schedule might be governed by approved access policy plus live access-control configuration. Office hours might be governed by an approved facility schedule. A particular service might have its own program owner and channel configuration. Do not designate a source merely because it is easy to edit.

A seven-step audit

1. Resolve the facility identity

Start with the stable facility ID and exact address. Record naming variants, but do not use a similar name, city, legacy label, or map pin as proof that two records describe the same facility.

2. Inventory every surface

List the official location page, blog or directions pages, map and directory profiles, customer portal, call script, chatbot knowledge, email templates, signage, lease or policy text, access-control configuration, property-management record, and any service-specific schedule.

The inventory is not a declaration that every surface is authoritative. It is the comparison set.

3. Preserve the exact published value

Capture the schedule as shown, including days, punctuation, 12-hour or 24-hour format, timezone, holiday language, and labels such as “24/7,” “closed,” or “by appointment.” Add the observation timestamp and a safe evidence reference.

Do not translate “office” into “support,” “access” into “open,” or “24/7 access” into “24/7 staffing.”

4. Name the governing source and source owner

For each field, ask:

• Which record is authorized to decide this value?
• Who owns that record?
• What approval is required to change it?
• What downstream systems consume it?
• How will a temporary exception expire?

If no answer exists, mark the field awaiting source-owner designation. That is a real control state, not a reason to guess.

5. Compare field by field

Compare Monday office hours only with Monday office hours. Compare access with access. Compare phone support with phone support. A schedule is matched only when its semantic label, facility, days, times, timezone, effective date, and exception policy agree.

6. Correct in a controlled order

Once the source owner approves an exact value, update the governing record first if necessary, then update dependent systems and public surfaces in a documented order. Preserve the old value and rollback route.

For higher-consequence access changes, verify configuration, authorization, and a safe test plan before changing any live access-control state. This checklist does not authorize an access-policy change.

7. Verify the result where people see it

Read back every corrected surface on desktop and narrow screens. Expand hour accordions. Test map, call, email, directions, rental, and support controls. Check structured data and cached copies where applicable. A successful save is not the same as a visible correction.

The 15-minute manager checklist

Choose one facility and answer these questions:

• □ Did I match the exact facility ID and address?
• □ Did I record office, access, and each material service separately?
• □ Did I capture the local timezone and effective date?
• □ Did I check the current official facility page and every linked hours surface?
• □ Did I record each source URL and observation timestamp?
• □ Did I preserve conflicting values instead of overwriting them in my notes?
• □ Is one governing source named for each field?
• □ Is one accountable source owner named for each governing source?
• □ Are holiday and temporary exceptions explicit?
• □ Did an authorized person approve the exact correction?
• □ Did I preserve the prior value and rollback route?
• □ Did I verify the visible result after publication?
• □ Did I avoid inferring staffing, ownership, service availability, or access performance from a label?

If any answer is no, the record is not ready to be treated as governed.

A practical exercise

Download the companion facility-hours audit template and use the Ocean Township public-page observations above as a tabletop exercise.

Your job is not to choose a winning page. Your job is to:

1. create separate rows for office and access hours;
2. preserve both observed office schedules with their URLs and timestamps;
3. mark access hours as publicly matched across the two pages;
4. mark office hours as conflicted;
5. leave the approved value blank;
6. name the role that must own the decision; and
7. define the evidence required before either public page is changed.

That exercise teaches the habit that matters most: a mismatch is an input to a decision process, not permission for an editor or automation to invent the answer.

Measure the control, not just the cleanup

Useful measures include:

• facility-hour fields reviewed divided by total in-scope fields;
• mismatched fields divided by fields reviewed;
• fields without a designated source owner divided by fields reviewed;
• time from conflict detection to source-owner confirmation;
• time from approval to publication;
• fields visibly verified divided by fields published; and
• repeat conflicts by source or workflow.

Always publish the numerator, denominator, period, source, and limitations together. A decline in visible conflicts could mean better governance, a smaller audit scope, or fewer checks. The measure needs context.

What this checklist does not establish

This method does not determine legal ownership, facility operation, employment, lease rights, access rights, staffing, emergency policy, or service availability. Public pages can be incomplete, stale, dynamically rendered, or in conflict. Internal systems can also be wrong. The purpose of the control is to surface uncertainty, route it to the accountable source owner, and verify the approved result.

Sources and limitations

Public observations were retrieved August 22, 2026 from:

• modSTORAGE Ocean Township facility page
• modSTORAGE Blog Ocean Township directions page
• modSTORAGE Long Island City facility page
• modSTORAGE Blog Long Island City directions page

These URLs are first-party published surfaces. They are cited to demonstrate field definitions and a dated public-source comparison. They are not represented as the governing internal source, proof of actual facility performance, or proof of a legal or operating relationship.

Disclosure

I am Chief Operating Officer of modSTORAGE. This article presents a governance checklist and dated public-page observations. It does not publish customer data, internal access settings, staffing records, or performance results, and it does not claim that any particular public schedule is operationally correct without source-owner confirmation.

The post Office Hours, Access Hours, and Service Hours Are Different Controls first appeared on modSTORAGE | Blog.

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.

The post The One-Page Facility Fact Sheet Every Manager Should Own first appeared on modSTORAGE | Blog.