HubSpot–Newbook Integration Case Study: Reservations, Stays and Guests for a Holiday Park Group
A park group holding one contact per booking and no record of who actually stayed. Booker separated from guest, reservation from stay, and site inventory joined to the account that occupies it.
CLIENT: Tarnbrook Leisure Group
Running Hospitality & Leisure on HubSpot, or thinking about it?
Schedule a consultationGET WEEKLY REVOPS INSIGHTS
No spam. Unsubscribe anytime.
Summary
Tarnbrook Leisure Group operates six holiday parks with 1,140 sites, taking roughly 19,000 reservations a year through Newbook. HubSpot held one contact per reservation, which meant one contact per booker, and no record of anyone else who stayed.
The engagement separated the booker from the guest and the reservation from the stay, and joined both to the site inventory that produced the revenue. Duplicate contacts fell from 6,200 to under 300, repeat-guest identification rose from 14 percent to 68 percent of arrivals, and cancelled reservations counted as revenue in the pipeline fell from 11 percent to zero.
Background: A Reservation Is Not a Stay
A reservation is an intention. A stay is what happened. The two agree most of the time, and the cases where they disagree are the ones that matter: cancellations, no-shows, shortened stays, and upgrades taken at arrival.
Tarnbrook's CRM recorded only the reservation, at the value it was booked at. Pipeline therefore counted revenue that had been cancelled, and a guest who extended by three nights appeared at the original figure. Haug, Zachariassen, and van Liempd (2011) separate the costs of poor data quality into the operational cost of working around defective data and the cost of decisions taken on it. A forecast built on cancelled bookings is the second, and it reaches a board paper before anyone books it against data.
Goodhue and Thompson (1995) surveyed users across two companies and found that performance improved where what a system offered matched what the task actually demanded, rather than where the system was simply more capable. Newbook was entirely capable of distinguishing a reservation from a stay. The CRM had no object for the second, so the distinction had nowhere to land.
The Audit
Two weeks against both systems and eighteen months of booking history.
Duplicates. 6,200 duplicate contacts, produced by the same household booking under different addresses across seasons, with no shared key.
Guest blindness. A reservation named one person. Average party size was 3.4, so the group held a record for roughly 29 percent of the people who actually stayed.
Phantom pipeline. 11 percent of reservations were cancelled and remained in pipeline reporting at full value, because cancellation was a status change in Newbook that never reached HubSpot.
Repeat identification. Only 14 percent of arrivals were identifiable as returning guests at check-in, despite an estimated repeat rate above 40 percent.
Identity Before Anything Moves
Three shapes were separated: the booker who transacts and pays, the guest who occupies a site, and the household that returns across seasons. One person is frequently all three, and the model has to allow that without collapsing them into one record.
The join key is the Newbook guest identifier, held on a dedicated HubSpot property with unique values enforced at creation. Household is a company record, which sounds odd for a leisure business and is the correct shape: it is a group of people who return together and whose value is the sum of what they collectively spend.
Wand and Wang (1996) treat an information system as a representation of the real world and define a data quality problem as a breakdown in that mapping. A record standing for a booking rather than for a person is precisely such a breakdown, and it is why the same family appeared four times.
The Build
Seven weeks across four phases, using the Newbook API, a nightly reconciliation job in the client's own tenancy, and a private HubSpot app for the write path.
Phase one, deduplication. The 6,200 duplicates were merged against an agreed survivorship rule, with an export taken first because merging is permanent.
Phase two, identity and household. The guest identifier was created and backfilled, and households were formed from shared address and payment instrument rather than from surname, which over-merges.
Phase three, reservation and stay. Reservation and stay became separate custom objects. The reservation carries what was booked; the stay carries what occurred, written at check-out with the final value, nights and site.
Phase four, cancellation. Cancellation in Newbook now removes the reservation from pipeline within the sync interval rather than leaving it to be noticed. Field ownership was assigned explicitly: Newbook owns availability, rate, reservation status and stay detail; HubSpot owns the relationship and marketing state.
Soh and Sia (2004) found that a gap between a package's assumptions and an organisation's structure can be closed only by changing the organisation, changing the package, or building at the boundary. A property management system assumes a booker, and building at the boundary is what allows a household to exist alongside one.
Outcomes
Duplicates. 6,200 before, 290 after, with the weekly unmatched count holding under 40.
Guest coverage. Records held for people who actually stayed rose from roughly 29 percent to 74 percent of party members, the remainder being children and guests who decline to be recorded.
Phantom pipeline. Cancelled reservations counted as revenue fell from 11 percent to zero, because status is now read rather than assumed.
Repeat identification. Returning guests identified at check-in rose from 14 percent to 68 percent of arrivals.
Value accuracy. Recorded stay value now reflects extensions and upgrades, which moved measured average stay value up 6 percent without any change in pricing.
Marketing precision. Off-season campaigns can now address households by their actual stay history, which was not previously possible.
What Resisted
Household formation resisted. The first rule merged on surname and postcode and over-merged badly, joining unrelated families in the same village and separating a couple with different surnames at one address.
The mechanism that resolved it was to require two independent signals rather than one: a shared address and a shared payment instrument, or a shared address and a prior reservation naming both parties. The stricter rule under-merges, which is the correct direction to fail in, because an unmerged household is a missed opportunity and a wrongly merged one is a privacy incident.
A second difficulty was operational. Park managers had been keeping their own arrival lists, annotated with preferences the CRM never held. Umble, Haft, and Umble (2003) catalogued what determines whether an enterprise-system implementation succeeds, and training and sustained involvement appear more reliably than any technical variable. Those annotations were migrated into guest notes before the spreadsheets were retired, because retiring them first would have destroyed information held nowhere else.
Limits
This does not prove the separation suits every operator. Tarnbrook's economics turn on repeat visits from households, where booker and guest diverge and the return is worth identifying. An operator selling mostly one-off single-occupancy stays should expect the two to be largely identical.
The household rule is also deliberately conservative and therefore under-merges. The 26 percent of party members with no record are not evenly distributed, and skew toward larger parties, so household value is understated for exactly the segment most worth understanding.
Figures come from the client's own reporting across both systems. No holdout was run, and the period included a tariff change that may have affected stay value independently.
Conclusion
The integration is a modelling decision rather than a connector one. Newbook always knew what had happened; the CRM had no object capable of receiving it.
The general form is that an intention and an outcome are different records. A system storing only the intention may be expected to report a pipeline describing what was hoped for rather than what occurred.
References
Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193
Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001
Goodhue, Dale L., and Ronald L. Thompson. 1995. "Task-Technology Fit and Individual Performance." MIS Quarterly 19 (2): 213–236. https://doi.org/10.2307/249689
Umble, Elisabeth J., Ronald R. Haft, and M. Michael Umble. 2003. "Enterprise Resource Planning: Implementation Procedures and Critical Success Factors." European Journal of Operational Research 146 (2): 241–257. https://doi.org/10.1016/S0377-2217(02)00547-7
Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479
Conflict of Interest
RevOps HQ is a HubSpot Solutions Partner and was engaged and paid by the client described.
Acknowledgments
Prepared by RevOps HQ.
Schedule a consultation
Thirty minutes, no deck. We look at your portal and tell you what this would involve for a hospitality & leisure business — including whether it is worth doing yet.