Your hours are wrong on Google. Now what?

A customer checks your hours, drives across town, and finds a locked door. Another calls because Google says you are open. Someone on your team changes the listing, but the old hours return a week later.

It is tempting to treat this as a small marketing mistake. Sometimes it is. More often, incorrect hours reveal that the business has no reliable way to decide, record, publish, and verify a basic fact.

The immediate correction matters. The operating system behind it matters more.

Correct the listing people are seeing

Start with the Google Business Profile that controls the location. Confirm that you are working in the right account and on the right listing, especially if the business has moved, changed names, or accumulated duplicate profiles.

Set the regular hours to the schedule the business actually follows. Use special hours for holidays, closures, events, and other exceptions. Do not change the ordinary weekly schedule to handle a temporary exception unless the schedule itself has changed.

Then inspect what a customer can see. Check the public profile, not only the management screen. Look at the day in question, the open or closed label, and any note about holiday hours. A saved edit is not the same thing as a verified result.

If the listing is owned or managed by an outside vendor, establish who can make the correction and who can approve it. Shared responsibility without a named owner is how a simple change waits until after the holiday has passed.

Find the source of truth

Ask a plain question: where are the official hours kept?

The answer might be a scheduling system, a staff calendar, a point-of-sale platform, a document, or the judgment of the person opening the building. If different teams give different answers, Google is only showing the disagreement that already exists inside the business.

Choose one source of truth. It should say what the regular schedule is, what exceptions are approved, when each change takes effect, and who approved it. It does not need to be complicated. It does need to be specific enough that two people reading it reach the same answer.

This is particularly important when a business has seasonal hours, appointment-only periods, separate departments, or several locations. A single field called hours may not describe the operation well enough.

Check every place the fact travels

Google is rarely the only place publishing your schedule. The website, maps services, social profiles, booking tools, directories, delivery platforms, printed signs, phone messages, and email confirmations may all repeat it.

Make a short inventory of those destinations. Record who controls each one and whether it is updated manually or through another system. That turns a vague instruction such as update everything into a checkable task.

Pay attention to integrations. A listing manager, directory service, or website plugin may be republishing an older value. If an incorrect hour returns after you fix it, look for a system with permission to write to the profile. Repeated manual corrections will not solve an automated overwrite.

The goal is not to connect every channel to everything else. It is to understand the path well enough that an approved change reaches the right places without creating a second, competing source.

Make temporary changes expire

Many errors begin with a legitimate exception. The shop closes early for an event. A team changes its Friday schedule for a season. A storm changes tomorrow's opening time. Someone publishes the update, but nobody records when it should end.

Every temporary change needs an effective date and an end date. It also needs an owner who will verify the public result. Without those details, temporary information becomes permanent by neglect.

A simple change record can hold the location, normal hours, exception, dates, affected channels, approver, publisher, and verification status. The value is not the form itself. The value is making the entire change visible before someone presses save.

Put verification into the workflow

Publishing should not be the last step. Verification should be.

After a change, have someone check the customer-facing result from outside the management account. The person should confirm the date, location, time zone, and open or closed status. If bookings or calls depend on the schedule, test the relevant path there too.

For an important closure or a location with frequent exceptions, check again when the change takes effect. Cached results and connected services do not always update together. A second look is cheaper than discovering the problem through an angry review.

Keep evidence of the check. A timestamp and a link may be enough. For a more controlled process, keep a screenshot with the change record. The point is to make verified mean something more than someone remembers editing it.

Decide when automation helps

Automation can help when approved hours already live in a dependable system and the same information must be published in several places. A small workflow might collect an approved exception, update selected channels, report failures, and create a verification task.

It should not guess whether the business is open. It should not silently resolve conflicting schedules. It should not publish a change without a clear owner and an audit trail.

The safest automation handles repetition while leaving judgment with the business. People decide the schedule. The workflow moves the approved fact, records what happened, and points out anything that did not update.

If the source information is unreliable, connecting more systems will spread the error faster. Clean up ownership and approval first. Automate only after the decision process is stable.

Treat the mistake as useful evidence

Incorrect hours cause immediate customer frustration, but they also show exactly where the operating process broke. Perhaps nobody owns the profile. Perhaps an old vendor still has access. Perhaps holiday decisions live in text messages. Perhaps the website and listing draw from different schedules.

Fixing that underlying break improves more than a search result. It gives staff a clear answer, reduces conflicting updates, and makes future exceptions easier to manage.

This is how we approach small operational problems that may need software. If there is a fit, we can build a working prototype before you pay so you can see how the source, approval, publishing, and verification steps would work together. The useful outcome is not a clever dashboard. It is that the next customer sees the right answer before leaving home.