Create a Change Log for Public Business Information

Executive summary

When a customer sees different hours or contact details in two places, staff need to know which value was approved, where it was changed and whether the public update actually went live. Without a change log, the team may repeat the same edits, undo a correct fix or lose the reason a field was updated.

A public-information change log is a small operational record, not a substitute for the authoritative source of truth. Allow 30 minutes to establish the fields and 5 minutes for each routine change.

Decide which changes need a log entry

Record changes that affect customer decisions or the accuracy of public information: business hours, phone numbers, addresses, service areas, prices, booking links, service names, eligibility terms, branch status and major contact routes. Minor typo fixes may use a lighter record if the team can still trace the change.

A log is especially useful when the same fact appears in several systems. It can show that the website was updated while a business profile edit remains pending, rather than implying that all channels changed at the same time.

Keep the record concise

Use fields such as:

change_id | fact changed | old value reference | approved new value | reason | source of truth | requested by | approver | systems affected | submitted_at | live_checked_at | status

Where possible, link to the approved source instead of duplicating sensitive information. Avoid storing passwords, recovery codes or unnecessary customer details. For a phone number or address, a reference to the approved record may be sufficient.

Use clear statuses: requested, approved, submitted, live verified, rejected, or blocked. Do not mark a change complete merely because somebody pressed Save or submitted a platform edit.

Separate the decision from the execution

The person who requests a change may not be authorised to approve it. For example, a staff member can report that branch hours are wrong, while the branch manager confirms the correct schedule. The publisher then updates the website or profile and checks the public result.

For material changes, record the effective date and whether old information should remain visible until that time. This matters for price changes, temporary closures and promotions. If several channels cannot be updated simultaneously, agree how to avoid misleading customers during the transition.

Verify the live state

After the update, open the public-facing page or listing and compare it with the approved value. If the platform shows a pending or rejected state, leave the record open and assign a follow-up action. Save a screenshot or URL when it materially helps future troubleshooting, but avoid retaining unnecessary personal information.

A platform’s edit history may show what changed inside that platform, while the business’s log explains why the change was authorised and how it relates to other channels. These records serve different purposes. Use both where available.

Resolve conflicts with a source-of-truth rule

If two systems disagree, do not choose whichever looks newer. Identify the person or business record authorised to confirm the fact. For opening hours, this may be the approved branch schedule; for prices, the current pricing record; for service coverage, the operations owner.

If the source itself is uncertain, mark the change blocked and ask for a decision. Publishing a guess across every channel can spread the error faster. Once confirmed, update the source of truth first or in a controlled sequence, then update dependent public placements.

Use the log to find process failures

Review unresolved changes weekly. Look for edits that remain pending, repeated corrections to the same field, or changes where no one can identify the approver. These patterns may indicate unclear ownership, missing evidence or a platform process that needs follow-up.

At month end, summarise the number of changes, average time to live verification, rejected edits and unresolved exceptions. Use the figures to improve the process rather than ranking staff by raw edit count.

Example: a branch phone-number change

The branch manager confirms the new number and effective date. The coordinator records the approved value and identifies the website, business profile, booking page and printed materials that contain the old number. Each owner updates their assigned touchpoint, and the coordinator checks the public result. Printed cards are marked for replacement rather than silently assumed corrected.

If one profile update is rejected, the change log remains open with the evidence and next action. Staff can still see which channels are correct and which need attention.

Keep the log usable during an urgent correction

For urgent changes, the coordinator can create a minimal entry first—fact, approved replacement, owner and affected channels—then add the remaining details after the public information is corrected. The emergency path should speed up coordination, not bypass approval of the underlying fact. Review urgent entries during the next routine check to ensure that every affected channel was verified and the record was completed.

Conclusion and next steps

Use a change log whenever public facts need coordinated updates. Record approval, affected systems and live verification, and keep unresolved items visible. The log makes discrepancies traceable and helps the team distinguish a requested change from a completed public update.