Hospitality has more digital tools than any other small-business sector, and fewer connected systems. Most venues run a reservation tool, a CMS, a POS, an email list, a CRM, and an ad account that never speak to each other. The cost is paid by the operator: every Monday morning, in time spent reconciling the weekend. The opportunity is paid by the guest, in messages never sent and reservations never confirmed. This report is a reference for what a connected stack looks like in 2026, and the architecture patterns that work at three scales.

The four-layer model.

Every working hospitality digital business runs the same four layers, regardless of scale. The architecture differs; the layers do not.

Layer 01 · Communication.

The surface that handles inbound contact. Phone, web form, messaging, social DM, email. For a small venue, this is one phone and one form. For a group, it's a routing layer that sends each message to the right venue or team. For a platform, it's the single-request flow plus the operator response loop.

The signal that this layer is broken: messages reaching the wrong person, response time over 24 hours on standard inquiries, and any inbound message arriving via three channels at once.

Layer 02 · Conversion.

The mechanism that turns intent into a booking. Reservations, event inquiries, gift-card purchases, ticket sales. The conversion layer must be completable on mobile, in under thirty seconds, with the venue's real availability and a confirmation that doesn't require human action to fire.

The signal that this layer is broken: reservation drop-off above 25% from form-start to confirmation, manual confirmations that delay guests by hours, and any reservation that requires the venue team to copy-paste an email to confirm.

Layer 03 · Operations.

The systems the venue team uses to run the shift, the week, and the month. Calendar, capacity rule, staffing, deposits, prep lists, follow-ups. This is where hospitality tech usually feels heaviest, because most platforms are built for chains, not for one specific room.

The signal that this layer is broken: more than one tab open during service, manual spreadsheet reconciliation at week end, and any operations question that requires asking the owner.

Layer 04 · Memory.

The retention layer. Guest history, preferences, return cadence, anniversaries. The thing every great maître d' does in their head, and the thing every venue forgets when they lose that person. The memory layer turns one-time visitors into regulars and regulars into hosts.

The signal that this layer is broken: a guest is treated as new on their fifth visit, an event birthday is missed by the follow-up email, and the venue cannot tell you the cadence of any specific repeat guest.

“Five disconnected tools is not a stack. It is a tax on the operator.”

Reference architectures · three scales.

Reference 01 · Single venue.

The smallest viable stack. One website, one reservation flow, one events form, one lightweight CRM, one email automation thread. Built so the owner can run a Saturday night without opening anything else.

Communication ─── one inbound surface (phone + web form)
Conversion ────── reservation + events flow on the site
Operations ────── single-screen ops view + automatic confirmations
Memory ────────── lightweight CRM with visit history
Cost band ─────── €25–60k build, €0–500/month run
Build time ────── 6–10 weeks
Live example ──── Incontro Bar (incontrobar.ch)

Reference 02 · Multi-venue group.

A group of 2–10 venues operating under one brand or one ownership. Each venue keeps its own conversion surface, while the operations and memory layers consolidate behind one shared system.

Communication ─── per-venue inbound surfaces + group routing layer
Conversion ────── per-venue reservation + cross-venue gift-card
Operations ────── shared operator dashboard with per-venue views
Memory ────────── unified CRM across the group with consent boundaries
Cost band ─────── €40–90k build, €500–1.5k/month run
Build time ────── 8–14 weeks
Pattern note ──── one venue ships first, the rest onboard in 2-week passes

Reference 03 · Event-location / hospitality platform.

A two-sided marketplace connecting demand (organisers, guests) with supply (venues, operators). The platform becomes the communication and conversion layer for both sides; each participating venue keeps its own operations and memory layers behind the matching.

Communication ─── one structured request → curated matching
Conversion ────── tailored proposals back inside 48 hours
Operations ────── two dashboards (organiser + venue), different products
Memory ────────── trust signals: response rate, reviews, named operator
Cost band ─────── €80–250k build, €1.5–5k/month run
Build time ────── 12–24 weeks
Live example ──── Dreilokale (dreilokale.ch)
From the studio

Morvion built both reference 01 (Incontro Bar) and reference 03 (Dreilokale) end-to-end in 2026, including the matching engine, CRM, CMS, and email automation. The same four-layer model applies; the architecture scales.

Cost bands · what to expect.

Public ranges from Morvion engagements in 2026, all-in (design + engineering + launch), excluding subscription tools the venue continues to pay for (e.g. payment processing, email-sending fees).

Discovery Sprint ──── €18–25k · 2 weeks · validates scope
Single venue stack ── €25–60k · 6–10 weeks
Multi-venue group ─── €40–90k · 8–14 weeks
Hospitality platform €80–250k · 12–24 weeks
Retainer (post-launch) €3–12k/month · ongoing iteration

The wider end of each band is driven by integrations: POS systems with custom APIs, legacy booking platforms that need shim layers, multi-language content, and gift-card providers with their own data models.

The 12-question self-audit scorecard.

For an operator to assess their current stack. One point per affirmative answer; max 12. Below 6 = a Discovery Sprint will surface cheaper, faster wins than another tool subscription. Below 4 = the operator is the integration layer and is the bottleneck.

  1. Does the website load in under 1.5 seconds on mobile 4G?
  2. Can a guest complete a reservation in under 30 seconds without leaving the site?
  3. Does the reservation confirmation arrive without anyone on the team pressing a button?
  4. Do inbound messages reach the right person without a triage step?
  5. Is there one tab the operator opens during service, not three?
  6. Does the operator know the visit history of a guest before they walk in?
  7. Are anniversaries, birthdays, and milestone visits actively followed up?
  8. Does the venue team update content (hours, menu, events) without engineering help?
  9. Can a new staff member learn the operational stack in their first shift?
  10. Is there a measurable retention signal the operator checks weekly?
  11. Are events and private hire flows separate from general reservations?
  12. Does the stack survive the team's busiest 30 minutes of the week?

What not to build.

The mistake we see most often: a venue, three months in, asking for a loyalty app. The answer is almost always no. Apps don't retain hospitality customers, rooms do. The digital stack should quietly make the room work better, not pull the guest out of it.

  • Branded loyalty apps below 5,000 active customers. The download cost exceeds the retention lift. Email, SMS, and well-timed messaging outperform.
  • NFT or web3 loyalty in 2026. Adoption among the guest demographic is too low to justify build cost.
  • AI “concierge” chatbots on the website. They cost trust faster than they save staff time. Use AI in the operational layer, not the guest surface.
  • Multi-venue super-apps for a single venue. The feature creep is paid by every operator who opens it.

Worked examples · two live builds.

Example 01 · Incontro Bar (Reference 01 · Single venue).

Incontro Bar is a Zürich aperitivo and afterwork venue. Morvion built the full single-venue stack end-to-end:

  • Communication: editorial homepage, contact form, events form, reservation flow on the same surface.
  • Conversion: reservation + events form with automatic confirmation, mobile-completable, no manual step.
  • Operations: single-screen ops view, the owner runs Saturday night without opening anything else.
  • Memory: lightweight CRM with visit history, used for return-cadence cues.

Example 02 · Dreilokale (Reference 03 · Hospitality platform).

Dreilokale is the Swiss event-location matching platform Morvion built end-to-end:

  • Communication: single structured request from the organiser, four to seven fields only the platform can match on.
  • Conversion: tailored venue proposals back inside 48 hours, organiser approves one or more.
  • Operations: two dashboards, organiser-side (track requests, see proposals) and venue-side (see inbound matches, respond inside the SLA).
  • Memory: trust signals across both sides, venue response rate, organiser request history, reviews after completed events.

Regional notes · Switzerland and DACH.

The architecture above applies broadly. A few Switzerland- and DACH-specific notes:

  • Regulatory: Swiss FADP (revised 2023) and EU GDPR/DSGVO both apply to most hospitality businesses. Consent boundaries on the memory layer are tighter than US norms. Build for opt-in retention from day one.
  • Multilingual: Zürich operates in DE plus EN tourist-facing. Vaud + Geneva operate in FR plus EN. Bilingual content is the floor, not a nice-to-have.
  • Payment rails: TWINT is non-optional for any consumer-facing payment surface in CH. Stripe + TWINT via PostFinance is the default combination Morvion ships.
  • Hospitality calendar: Swiss public holidays differ by canton; the operations layer must respect that, not bake in a single national calendar.
Field rule

A hospitality digital stack is not finished when the website ships. It is finished when the operator stops opening a second tab.

The stack is built across two practices: Experience Design & Interactive Worlds for the communication and conversion layers, and Digital Products & Platforms for the operations and memory layers. Many engagements start with a two-week Discovery Sprint that locks the four-layer scope and the integration surface before any production build.

For the long-form discussion of these patterns, see the field notes on hospitality digital systems and marketplace design principles. For the one-paragraph definitions of the underlying terms, see the glossary entries on hospitality website and marketplace platform.

Versioning of this report.

This document is versioned. Substantial revisions (new reference architecture, new cost band, new region notes) bump the major version. Minor refinements are silent. Current version: 1.0.0, published 2026-05-18.

Common questions.

What is the hospitality digital stack?
The hospitality digital stack is the set of connected systems a venue, group, or platform runs across four layers: communication (phone, messaging, forms), conversion (reservations, events, gift cards), operations (calendar, capacity, staffing), and memory (guest history, retention, returns). Modern hospitality businesses succeed when those four layers operate as one system, not five disconnected tools.
What does a working hospitality digital stack include?
At minimum: a website that loads in under 1.5s and books in under 30s, an automatic reservation and confirmation flow, an events form that pre-qualifies and routes, a lightweight CRM or CMS the venue team can self-manage, and a monthly retention layer based on real visit data. Beyond that minimum, optional layers include marketplace listings, multi-venue group dashboards, and AI-supported drafting for inbound messages.
How much does a hospitality digital stack cost?
Morvion engagement bands: small single-venue website + CMS + light CRM lands €25–60k. Multi-venue group with shared CRM lands €40–90k. Event-location platform (two-sided marketplace) lands €80–250k depending on complexity. A two-week Discovery Sprint at €18–25k typically precedes the build and locks the scope before any production commitment.
How long does a hospitality digital build take?
Single-venue website + lightweight CRM: 6–10 weeks from kickoff to launch. Multi-venue group system: 8–14 weeks. Event-location platform: 12–24 weeks. A working preview lands inside the first 3–6 weeks of any engagement.
Does this apply outside Switzerland?
Yes. The reference architectures are agnostic to geography. The cost ranges, the regulatory considerations (DSGVO/FADP), and the matching logic for Dreilokale are Swiss-specific, but the four-layer model and the scorecard apply to any hospitality digital business in Europe.
Has Morvion built any of these stacks?
Yes. Incontro Bar (Zürich aperitivo venue) is live at incontrobar.ch as a single-venue hospitality stack. Dreilokale is live at dreilokale.ch as the platform tier: the Swiss event-location matching marketplace Morvion built end-to-end. Both are referenced in the worked examples below.