Key takeaways
- Maintain one approved schedule for each location, service, department, appointment mode, and time zone.
- Use regular hours for normal customer-facing availability and special hours for holidays or temporary exceptions.
- Propagate changes to the profile, site, schema, booking, phone, ads, directories, and physical signage from one change event.
- Monitor source drift and customer-impacting mismatches rather than treating a successful API call as completion.
01
The locked door is where the data model becomes real
The website says the shop closes at six. Maps says seven. The booking tool accepts a 6:30 appointment, and the phone message says holiday hours will be posted online. Every system is technically working. Together they have sent a customer across town to wait outside.
Create an availability record for each location and service with time zone, regular customer-facing hours, appointment rules, service or department hours, seasonal pattern, holiday exceptions, emergency state, effective dates, approver, and last verified time. Distinguish a staffed premises from a phone line, delivery window, or online service.
Swipe to compare every column
| Availability type | Use | Example failure |
|---|---|---|
| Regular hours | Normal customer-facing schedule | Phone support mistaken for an open shop |
| Special hours | Holiday or temporary exception | Editing the recurring schedule for one day |
| More hours | A distinct service or department | One department shown as the whole business |
| Appointment only | Access that requires booking | Showing unrestricted walk-in availability |
02
Publish the kind of availability the customer can use
Google asks businesses to publish regular customer-facing hours and use special hours for holidays or known exceptions. Some business types have specific guidance. “Open 24 hours” should not describe a voicemail box, an unstaffed website, or an emergency number when a customer expects a physical service.
Explain material constraints near the hours: appointments required, last admission, kitchen closing earlier, pickup only, seasonal closure, or departments with different schedules. Structured data should match the visible page and real operation; it is not a place to publish a more attractive version.
03
Treat every exception as a release
Schedule known holidays weeks ahead. Generate one approved change event that updates Business Profile, location page, LocalBusiness markup, booking inventory, call routing, campaign extensions, directory feeds, email signatures where relevant, and the sign on the door. Include an effective time and a rollback.
For weather, staffing, or utility emergencies, give a small on-call group permission to activate a pre-defined temporary state. Record who changed it, where it propagated, what failed, and when normal hours should return. A stale emergency closure can be as damaging as a missed one.
04
Verify the customer-facing result
Check the live profile and rendered site, not only the source record. Sample calls, bookings, major directories, and mobile search. Reconcile changes returned by platform updates or user suggestions before accepting them into the authoritative record.
Monitor mismatched hours, failed propagation, stale exceptions, bookings outside staffed periods, calls during closures, and customer reports. The useful service level is the time from an approved operational change to accurate customer-facing availability everywhere that matters.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- Google: Guidelines for representing your business
- Google: Edit your business hours
- Google Business Profile APIs: Work with location data
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem



