23 touchpoints, one system

This article tracks a single guest (a 38-year-old marketing director called Sarah, planning a long weekend at a country house hotel for her parents' wedding anniversary) through twenty-three distinct digital touchpoints with a hospitality operator. From the first Google search to the post-stay review request, every interaction is recorded against the same canonical guest record, every behavioural signal feeds the next decision, every operational event can fire a marketing trigger if the operator chooses to wire it in.

The point isn't the journey. The point is that every touchpoint depends on data from a different operational system, and the entire journey only holds together because all those systems share one database.

In a fragmented stack, the journey breaks at the seams. Sarah is treated as a new customer at touchpoint 6, then again at touchpoint 14, then again at touchpoint 19. Her preferences aren't remembered. Her loyalty status doesn't follow her. Her marketing consent has to be re-collected. The operational staff have no context. The marketing team have no attribution. Eighteen of the twenty-three touchpoints fall into operational dark.

In unified architecture, every touchpoint stays in the light. Here's what that looks like.

Touchpoints 1–10: before she arrives

Touchpoint 1: Sarah Googles "Cotswolds hotels with private dining for 8." She lands on a venue page on the operator's website. The CMS is the same platform as everything else. The page she sees is dynamically rendered with availability for her dates pulled live from the PMS. There's no third-party booking widget that takes her to a different domain.

Touchpoint 2: She connects to the venue WiFi during a scoping visit two weeks earlier (her parents live nearby, she'd dropped in for coffee). The captive portal recognises her email (the same guest record) and a first-WiFi-login trigger had fired at the time, enrolling her in a low-pressure nurture flow about the venue. She doesn't know this. She just remembers liking the place.

Touchpoint 3: She fills the private dining enquiry form on the venue page. The space enquiry trigger fires. The venue's events coordinator receives a notification. Sarah receives an auto-confirmation email with the private dining brochure PDF, attached automatically because the form is wired to the venue's document library. Total latency from form submit to email delivered: under 30 seconds.

Touchpoint 4: Two hours later, the events coordinator emails Sarah personally with a quote. The coordinator's email is sent from inside the mDOS unified inbox. The reply lands in the same thread. The thread is attached to Sarah's contact record. The deal is created automatically with a stage of "Enquiry: Quoted."

Touchpoint 5: Sarah accepts the quote and books eight covers in the private dining room for Saturday evening. The booking is recorded against her contact record. The deposit is taken via Stripe Connect on the venue's connected account. The space-deposit-paid trigger fires and enrols Sarah in a pre-event nurture flow: pre-arrival menu confirmation at -7 days, dietary requirements form at -5 days, sommelier wine pre-selection at -3 days, arrival logistics at -1 day. None of these are written or sent manually. They run because the flow was built once, six months ago, and now runs for every private dining booking across the estate.

Touchpoint 6: Three weeks before the event, Sarah books bedrooms for herself and her parents for the same night. The booking widget recognises her email (the same guest record) and pre-fills her name, phone, and address. Both her PMS booking and her existing private dining booking resolve to the same canonical contact record, so the team sees them together against one guest, and her dietary preferences from the events form are visible to the F&B team. She gets one confirmation email with everything in it, not three from three different vendors.

Touchpoint 7: Two weeks before, Sarah forgets to fill in the dietary requirements form. The form-submitted trigger that was supposed to fire never fires. A separate inactivity trigger against the events workflow fires instead at -10 days. Sarah gets a gentle nudge email: "Quick one: do any of your guests have allergies or dietary requirements we should know about?" She clicks through, fills the form, the flow continues.

Touchpoint 8: One week before, she abandons her booking on a casual dining sister venue she also wanted to visit on the Friday night before the anniversary dinner. She'd been picking dishes for a pre-order, distracted by a work call, and closed the tab. The abandoned-booking trigger fires. Forty-five minutes later she gets an email: "Your table at [venue] is still held. Just one tap to confirm." One-tap link. She confirms.

Touchpoint 9: Three days before, the sommelier pre-selection email lands. She picks three wines from a curated list. Her selections are saved as the event's pre-orders, the same list the kitchen and bar will read from on the night. The sommelier's choices on Sarah's pre-selection email were filtered to wines actually in stock at that venue this week, drawn from the same stock system the bar manager uses for ordering.

Touchpoint 10: One day before, the arrival logistics email lands. Driving directions. Check-in time. WiFi password. Restaurant booking confirmation. Private dining room location. Anniversary menu PDF (sent because Sarah ticked "celebrating a special occasion" on the original enquiry, which set a tag, which conditioned this flow). All in one email, branded to the venue, signed by the General Manager.

Touchpoints 11–19: the stay and its aftermath

Touchpoint 11: Sarah arrives at 3pm Saturday and checks in. The check-in is recorded in the database. Her checking in triggers two things autonomously: the welcome flow (a message using her name, with her room preferences from a previous stay already on her record for the team) and the spa upsell trigger, "You're with us for two nights. Would you like to add the couples' massage tomorrow morning?" Sarah books the treatment from the link in the message. The booking writes back to the PMS as an extra charged to the folio.

Touchpoint 12: Friday evening's casual dining booking happens at the sister venue. The till bills the meal to Sarah's contact record. The completed-till-order trigger fires. Loyalty points are calculated and granted atomically inside the same transaction as the bill payment. Her loyalty tier ticks from Silver to Gold. The loyalty tier upgrade trigger fires, enrolling her in a tier-up flow that will land Sunday morning.

Touchpoint 13: The bottle of Châteauneuf at the private dining dinner Saturday night fires the purchase-by-category trigger for wine. You read about this in our wine-pairing article.

Touchpoint 14: Sarah checks out Sunday at 11am. The check-out trigger fires. Folio is settled. Receipt is emailed automatically. The post-stay review request isn't sent immediately: the flow is configured to delay until +48 hours post-checkout, which is when most guests are emotionally ready to write a meaningful review rather than a rushed one in the car park. This decision was made by the marketing team based on review-response-rate analytics from the platform's own data.

Touchpoint 15: Tuesday morning, Sarah's review request lands. She clicks through to the platform's first-party review form. She rates the stay 5 stars. The positive review trigger fires. She's now eligible for the referral flow, the next-stay-discount-for-recommending-a-friend flow that the marketing team built six months ago.

Touchpoint 16: Wednesday, the wine-pairing email lands.

Touchpoint 17: Sarah's parents (never having interacted with the venue's marketing system) receive a thank-you email from the General Manager. The events coordinator wrote this manually, in the unified inbox, addressed to the booker's named guests because their details were captured at touchpoint 7. The parents are now their own contact records in the CRM, captured against the same booking. Future flows can reach them with appropriate consent.

Touchpoint 18: Two months later, Sarah's father's birthday is approaching. The loyalty member's birthday trigger fires (he'd been added to the loyalty programme at touchpoint 17 via implicit enrolment with marketing consent). He gets a birthday email with a tier-appropriate offer for a return stay.

Touchpoint 19: He books. The whole loop starts again, this time with the venue already knowing the family, the room preferences, the dietary requirements, the wine taste.

Touchpoints 20–23: the operational layer

Touchpoints 20 through 23 are operational triggers that fire silently in the background and never reach Sarah directly, but improve every staff interaction she has: the night audit being locked, finalising the books; a maintenance request, from her note about a leaking shower, being logged against the room and resolved before the next guest arrives; a concierge request, from her request for a restaurant booking nearby; and a corporate account being created, because her company has now used the venue four times and a corporate rate is being set up.

What the journey proves

The journey above is twenty-three touchpoints. It uses sixteen distinct triggers out of the more than 150 wired into the mDOS flow engine. No single touchpoint is unique to mDOS. Every operator could theoretically build any one of them in a fragmented stack with enough integration work.

What's unique to mDOS is that all twenty-three touchpoints stay attached to the same canonical guest record from beginning to end, that the data each touchpoint depends on is one query away in the same database, and that the flows that govern the journey can be built and modified by the marketing team in the platform's UI, not by an integration agency.

This is what "embedded into the operational realities of the venue" means. The marketing engine isn't bolted onto the operational systems. It's part of them. Every operational event is a marketing trigger waiting to be wired up. Every marketing trigger is an operational event that already exists in the database.

The 150+ triggers are the surface area. The unified database is what makes the surface area possible.

---

Talk to the founder about how the architecture would fit your estate.