You are not selling a product. You are selling a Tuesday at 7 p.m. — a seat at a table that exists once and never again. Escape rooms, supper clubs, tasting menus, hands-on workshops: the phygital experience business trades in time and space, not SKUs, and that single difference breaks most commerce tooling, which assumes an item you can restock. On VBWD the unit of sale is a seat, and the constellation that makes it work is booking for the seats and time slots, cms for the landing and story, bot_telegram for discovery and reminders, token_payment for prepaid credits, and email for the receipt. The invoice line item is not a thing in a box. It is a seat at a specific hour, and the platform treats it that way natively.

Constellation diagram: booking-based timed seats sold through a CMS landing page, discovered and reminded via a Telegram bot, prepaid with token credits, with email receipts

The reason phygital experiences are awkward to sell online is that a seat is perishable and scarce in a way a mug is not. Sell one too many and you have an overbooked room and an angry guest; sell one too few and the empty chair is revenue you can never recover. VBWD's booking plugin is built for exactly this — appointments, rooms, spaces, seats, time slots — so the scarcity is modeled correctly from the first line of the order.

Booking is the product, and the seat is the line item

Lead with the piece that changes everything. The booking plugin handles appointments, rooms, spaces, seats, and slots, which means a 6-person supper club at 8 p.m. on Friday is a real, bounded, sellable object with exactly six seats and a hard start time. When a guest buys, they consume one of those seats, and the platform's point of truth — the invoice line item — records the sale of that seat at that hour. There is no pretending a time slot is a stock unit. Overbooking is prevented by the seat count, not by a spreadsheet someone forgot to update. Sell-outs are visible. Waitlists become meaningful because the scarcity is honest.

This is the non-trivial inversion worth sitting with: most commerce stacks make you contort a time-and-space business into a product catalogue. VBWD lets you sell time and space as themselves. Because the whole platform declares against one shared invoice interface, a seat sold through booking reconciles alongside everything else — credits, discounts, add-ons — without a bolt-on reservations system living off to the side.

CMS tells the story that sells the seat

Experiences sell on narrative. Nobody books a "2-hour slot"; they book the promise of a candlelit five-course dinner or a locked-room mystery with a real ticking clock. The cms plugin gives you the content, pages, and blog to build that anticipation — the landing page, the menu, the photos, the story of the host, the reviews. The CMS is the front of house; booking is the reservation book. They live in the same deployment, so the "Book Friday, 8 p.m." button on a beautifully told page leads straight into a real seat on a real slot, with no integration seam between the marketing and the availability.

Telegram is where discovery and reminders actually land

For local, time-bound experiences, the hardest problems are being discovered and being remembered. A great supper club with no audience is empty; a booked guest who forgets is a no-show that cost you a seat you could have resold. The bot_telegram plugin addresses both. A channel or bot announces new slots the moment they open — "three seats left for Saturday's tasting" — turning discovery into a push rather than a hope that someone visits your site. And because the bot has a direct line to the guest, it sends the reminders that make phygital economics work: the day-before nudge, the two-hours-out "your table is ready," the "here's how to find the door." Reminders are not a nicety in this business; a reduced no-show rate is the difference between a full room and a half-empty one, and the bot is what delivers them where people actually read.

Prepaid credits and receipts by email

Experiences are best sold prepaid — you want the seat committed and paid before the night, not a card swiped at the door. The token_payment plugin gives you a credit economy that fits this naturally: guests buy credits and spend them on seats, which also makes gift bundles, class packs, and "buy 5 sessions" offerings trivial, since a package is just a credit balance. A regular at a workshop series holds a balance and books against it; a gift-giver buys credits someone else redeems. Every spend is, again, an invoice line item, so the prepaid balance and the seat it buys stay reconciled.

Behind the credits sits VBWD's provider-agnostic payment core, so guests can top up with whatever their market uses — a card, a regional rail, or non-custodial crypto that settles to your own wallet — without you building each integration. And when the booking is confirmed, email delivers the thing every guest expects: the receipt, the confirmation, the details of where and when. The event-driven core with native signed webhooks means that confirmation email is triggered by the booking event itself, reliably, rather than by a human remembering to send it.

The honest boundary

Here is the caveat, and for experiences it is not a footnote. VBWD sells the seat, takes the money, and reminds the guest — but it does not run the night. The room still has to be built, the food still has to be cooked, the host still has to show up, and the experience still has to be worth the seat. The platform gives you flawless availability, prepaid billing, discovery, and reminders; it does not give you a business that people want to attend. It also does not manage the physical operations — capacity safety, staffing, the logistics of the actual space — which remain entirely yours, along with the work of self-hosting the deployment. VBWD removes the reservations-and-billing engineering, not the craft of hospitality.

Why this is buildable, not theoretical

Each plugin here is a real, shipping capability. booking already models seats and slots; cms already runs content-driven landing pages; bot_telegram already powers Telegram bots; token_payment already runs credit economies; and email confirmations ride the event-driven core. The platform has already carried verticals as varied as a tarot app, a dice-market game, a pharmacy shop, and dataset publishing, which is the evidence that these seams hold when a real product depends on them. A timed-seat experience business is not a new build — it is booking as the product, with a story in front of it and a Telegram bot beside it.

Clone the public SDK at github.com/VBWD-platform/vbwd-sdk-public, read the booking and bot guides at vbwd.cc/docs, and if you run experiences and want to sell seats properly, reach us at vbwd.cc/contact.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.