How to Build a Hotel Content Source of Truth

A source of truth is useful only when people know what question it answers. For listing content, define it as the approved operational value for each guest-facing fact: the hotel's check-in start, whether breakfast is available, the terms on which it is included, a room's bed configuration, or the limits attached to a pet policy. It is not the guest-facing wording itself, and it is not a copy of whatever a channel happens to show today.

Keep the boundary narrow enough to maintain. Rates, availability, inventory, contracts, photography rights, and legal policy documents may have their own systems or owners. The listing record can point to those authorities instead of reproducing every detail. For a rate-level cancellation condition, for example, record the approved interpretation and identify the controlled rate plan or policy document where the full terms live.

Write down the purpose, who may approve a change, and which content domains are included. If a disputed value has no known owner or evidence, record that uncertainty and assign a decision; do not silently promote a public listing into the authority just because it is easy to find.

Use one field for one fact that can be approved and changed independently. A long property description may combine breakfast hours, a paid shuttle, and a pet restriction; if only one changes, a single paragraph leaves the team unsure which claim was reviewed. Split the record into values that have an identifiable owner and a clear verification method.

Add the level at which each value applies. Expedia Group's Rapid content documentation represents amenities at property, room, and rate-plan levels; Google's Lodging model separates property information from guest-unit information. These are platform data models, not a universal hotel schema, but they show why scope belongs beside the value rather than in an editor's memory.

Capture relevant conditions in the same row or linked record: dates, days of week, guest limits, unit type, charge basis, currency, language, or advance-notice rule. A bare 'breakfast included' can conceal whether the statement means a service is available property-wide or is included only with selected rates. Keep each condition that changes the guest-facing meaning attached to the approved fact.

Start with the systems and working habits already in place. A small property may be able to maintain a shared worksheet; a larger operation may need a content platform, property-level register, or controlled document library. The important choice is whether the home makes the current approved value, owner, scope, evidence, and change history easy to find and update.

Use a simple decision check: can the right people access it; can they see who changed a value and when; can an approver distinguish a proposal from an approved value; can the record represent property, unit, and rate exceptions; and can teams export or reuse the data without retyping it? If the answer is no to the controls the operation depends on, choose another home or add a lightweight process around it.

Avoid making several uncontrolled copies. If an operating system remains the actual authority for a value, make that relationship explicit and link to it. If a channel manager distributes selected fields, document which fields and destinations are in scope; do not assume that every content category or connection behaves the same way. A record can be the governance index while a specialist system remains the source for a particular data domain.

• Name the record's owner and the systems it points to.
• Keep one clearly marked current version; archive superseded versions rather than editing history away.
• Test access, approval, export, and recovery with the people who maintain and use the record.
• Do not buy or build a new platform until the missing control is specific and understood.

The person who maintains the record is not automatically the person who can approve every value. Give each field an operational owner who can confirm the reality behind it, such as front office for arrival procedures, facilities for parking, or food and beverage for meal service. Give a content steward responsibility for keeping the register organised, applying approved changes, and following up on unanswered questions.

Define who can propose a change, who must confirm it, and who marks it approved. Keep the approval close to the record: person or role, date, and the evidence reviewed. A chat message or a forwarded document can alert the steward, but the register should show the final decision and link to the underlying instruction or policy.

For a group, separate a shared standard from a property's approved local value. Make the default visible, and require a local exception to name the property or room, the reason, the approving role, and any date when the exception expires or needs review. This lets the group reuse common facts without erasing genuine operating differences. The linked multi-property guide covers that portfolio workflow in more detail.

• ✓Every active field has one accountable owner, even when several teams contribute.
• ✓A proposed value cannot be mistaken for an approved value.
• ✓An exception names the affected property, room, rate, or date range.
• ✓A vacant role or unanswered question has a named interim owner and a next action.

A blank cell is ambiguous: the information may be unknown, not applicable, unapproved, or simply not entered yet. Use a short controlled status alongside the value, such as approved, pending confirmation, not applicable, varies by scope, or temporarily unavailable. Define each status so one editor's 'pending' does not mean another editor's 'probably yes'.

Do not fill an uncertain value by copying the majority of OTA listings. They may all repeat the same old instruction, and none of them establishes what the hotel currently operates. Route an unresolved fact to its owner, keep it out of approved channel copy until it is resolved, and record the decision needed to close the gap.

Keep operational exceptions specific rather than embedding them in broad notes. If the pool closes for renovation, identify the affected service, dates, property areas, and the person who will confirm reopening. If a service varies by room, list the affected room types. If a price changes by currency or charging basis, preserve those units so a later editor does not compare unlike values.

Separate the approved internal status from the status of a public listing. 'Approved' means the hotel's owner confirmed the value; it does not mean every channel displays it correctly. Public evidence and correction status belong in the audit workflow, which has its own states for matches, conflicts, missing pages, and inaccessible sources.

Store when a change was approved, when it becomes effective, who approved it, why it changed, and what previous value it replaced. Keep the current value easy to read while retaining a change log that lets an editor reconstruct the decision. A review date is a prompt to confirm the value, not proof that it is still true.

The evidence should be close to the value: a current policy, service configuration, operations instruction, signed decision, or a named system record. Add a link or document identifier plus the date it was checked. If the source is temporary or likely to change, record what event should trigger another review instead of relying on a distant calendar reminder.

Platform timestamps can help illustrate why dates matter without dictating a hotel-wide format. Google's Lodging schema requires a last-updated timestamp for its data, but that field describes Google's model. For an internal record, choose a consistent time zone and date format and distinguish approval time from the date the operational value takes effect.

Do not try to transcribe every sentence on every channel before the record has a clear owner. Begin with a bounded set of high-consequence facts that the team can verify from its operating sources. For each one, confirm the approved value, conditions, scope, owner, supporting evidence, and next review point. Mark anything unresolved instead of giving the sheet an appearance of completeness it has not earned.

The free CSV template is a starting worksheet, not a prescribed data model. It includes a field, scope, approved value, conditions, owner, effective date, review date, and evidence source. Replace or extend rows to fit the property, and add a property or room identifier if the same register covers more than one property or unit. Keep the column meanings stable so an export remains understandable to the next editor.

Before sharing it widely, walk through a change with the field owner: find the current fact, verify its source, propose a correction, approve it, set the effective date, and preserve the previous value. That short walkthrough will reveal whether people can tell who decides, where evidence lives, and how an exception is represented. Adjust the process before inviting broad edits.

A source of truth stays useful when a real operating change updates it before that change is forgotten. Attach a record update to the work that already approves a new policy, service, fee, room type, renovation, seasonal schedule, or property opening. The steward checks which facts are affected, asks each owner for confirmation, and stores the approved version with its effective date.

Set a review rhythm the team can actually maintain for facts that do not have a natural trigger, and let owners change it when the risk or pace of change differs. Do not treat an arbitrary interval as a universal rule. A time-sensitive temporary closure needs a different reminder from a stable property address; the owner should set the next check based on the fact and the evidence behind it.

When the record is ready, use it to guide a public listing audit and then verify what guests can see. MisMatchMaker can compare public evidence for supported factual fields, but the internal record remains the hotel's responsibility and many content areas need a manual check. Keep the source record, channel submission, and public result as distinct stages so a saved approval is never mistaken for publication.