The phrase is useful right up until someone uses it to claim one platform owns everything.
A hotel has several kinds of truth: the room’s physical facts, the buyer’s requirements, the commercial terms, inventory and the approved event instructions. They need clear relationships, not a vague promise that one database has become the hotel.
Any vendor can put “single source of truth” on a slide. I want to know who gets the phone call when the floorplan, the sales presentation and the event order disagree. Start with “truth about what?” and the actual person who can answer.
Give each kind of fact an owner
For every fact that matters, name the system that owns it, the person who approves changes, who can read it and how updates happen. Decide which copies are just references and which can be edited.
A ballroom’s capacity and a date-specific hold on that ballroom are different things. The first can’t prove the second.
What lives in Delphi, and what lives with the room
Here’s the concrete version, using Delphi as the example sales-and-catering system:
- With the room (reusable property content): its one correct name and ID, photos and 360s, dimensions, setups and capacities, floorplans, current collateral.
- In Delphi (the deal): the buyer’s requirements, the opportunity stage, negotiated terms, the event-specific commitments.
A proposal or Deal Room pulls from both. It shows the right room content for this program without becoming the authority on price or availability.
That split matters most when something changes. If the client’s headcount changes, the seller updates the opportunity and rechecks the recommendation. If the room changes, the content owner updates the room and rechecks every proposal that used it. Different change, different owner.
Plan for disagreements
Which source wins when names don’t match? What happens when a copy goes stale? How does the team know a value is waiting for approval?
Don’t let the newest timestamp win every argument. A recent unchecked edit can be less trustworthy than an older approved fact.
Before connecting systems, map the IDs: which Delphi room code matches which room record, how airwall sections are represented, which fields get copied and which only get referenced. A mapping on paper is design work. It doesn’t mean anything is syncing.
Give every copy a job
A buyer presentation can show room facts without becoming their master. An export can support a review without becoming the event’s authority. A public web page can explain a space without claiming live availability.
Write down where updates need a manual check. Emailed files and hand-typed copies won’t follow the source automatically.
Test the chain
Pick three changes: a room rename, a client requirement change and a deal stage change. Ask where each one is approved and what has to be checked afterward.
If nobody can answer, a new integration will just move the confusion faster.
One clear source for each kind of fact is a sensible goal. One system pretending every fact belongs to it is a different proposition.
The hotel needs dependable answers and accountable owners more than it needs a comforting slogan.
Related: Why Hotel Integration Projects Fail Before the API Call. For a starting framework, see our hotel sales technology stack guide.
