Try the live demo
One-click demo sign-in for every role on a seeded venue that resets daily — explore the real product in seconds without creating an account.
You can try the real product — not a mock-up — in seconds. The landing page at https://dineglobe.com/#demo carries a “Try the live demo” section with one-click sign-in cards for every staff role on a seeded demo venue, plus a guest card that opens the real public booking flow. There is nothing to install, no account to create, and no email to wait for.
Where the demo lives
Scroll to “Try the live demo” on the landing page. The section renders only while the demo venue is publicly visible and the demo is switched on; if it is ever disabled, the whole section simply disappears and sign-ins are refused with DEMO_UNAVAILABLE — the demo is never shown in a fake state.
The seeded venue
The demo runs on one purpose-built venue:
| Fact | Value |
|---|---|
| Name | DineGlobe Demo Venue |
| Public address | dineglobe-demo — see /dineglobe-demo |
| City | New York, US |
| Timezone / currency | UTC / USD |
| Status | PUBLISHED (it appears in the public directory like any real venue) |
| Waitlist | Enabled |
| Service | Dinner, 17:00–23:00 |
Its “today” is a full service narrative: eleven reservations across the day’s lifecycle states — confirmed dinners, a cancelled lunch, a no-show, a pending request and a walk-in — two tables seated right now, and two parties waiting in the queue.
Every identity in the demo is synthetic: guest addresses end in @guest.demo.invalid and demo staff accounts in @demo.dineglobe.internal. No pilot organization’s data is ever touched, and demo bookings never send email or SMS — the seed writes no outbox jobs at all.
The role cards
| Card | Button | Where it takes you |
|---|---|---|
| Book as a guest | Open the booking page | /dineglobe-demo/book — the real public booking flow, no account |
| Host | Open the host board | The demo venue’s today board |
| Door | Watch the floor | The same board, with door-scoped permissions |
| Manager | Review the day | The same board, with manager permissions |
| Owner | Enter the console | /app — the console home, org-wide |
Each staff card provisions a fresh, real account: a registered identity whose randomly generated password is discarded the moment it is created (nobody can sign back in), a real membership row — OWNER is org-wide on the demo organization, HOST/DOOR/MANAGER are venue-scoped — and a normal revocable session. The demo grants exactly what the permission matrix grants: no impersonation, no bypass, no extra powers. Because it is a real session, a demo sign-in replaces any console session you already have — the cards disclose that.
What each role can actually try
- Guest — pick a service, party size and date; see genuinely computed times (including “too soon — call us” slots inside the notice window); book and receive a
DG-confirmation code. The confirmation screen itself notes that changing or cancelling from that screen is not available in the pilot yet. - Host — the day’s board with live booking statuses, table labels and visit progress (“Arrived 2/4”); the “Floor right now” occupancy list; walk-in and phone intake through “Add booking”; and the reservation actions: record arrival, seat the party, record departure (tables release for cleaning), cancel with a reason, and mark a no-show after the grace window.
- Door — the same board and reservation detail, contact-free: door roles record arrivals (typed code or pass entry — the camera scanner is not built in the current version) but cannot book, seat, cancel or manage the queue.
- Manager — the widest staff permission set on the same board. Manager-only surfaces that have no screen yet — request decisions, reports, the floor-plan and policy editors — appear on the landing page as plain roadmap text, never as fake screens.
- Owner — everything above, plus the console home at
/app: the venues list, the add-a-venue flow, and Account & security at /app/account, where you can switch on two-step verification, review signed-in sessions and revoke them.
The daily reset
The demo’s “today” is rebuilt from its seed twice a day, at 00:17 and 18:37 UTC. The rebuild deletes and recreates only the demo venue’s same-day data, so the narrative is fresh every morning and the “seated now” evening scene is re-seated again before the service.
One honest gap is part of the design: the business date rolls at midnight UTC, and the reset runs 17 minutes later. In that window the board shows the new date against yesterday’s narrative — accepted and disclosed, never papered over. Demo accounts are also housekept: accounts older than 7 days are disabled by the reset.
Limits worth knowing
- Rate limit: 10 demo sign-ins per hour per client IP, counted before any account is created. Past the limit the button answers: “Too many demo sign-ins from this network — try again later.”
- A demo sign-in replaces your current console session (including one from an earlier demo card).
- The seeded venue is genuinely published, so it legitimately appears in the public directory, the landing’s pilot-venues list and the sitemap.
- Roadmap-only features — waitlist board UI, request decisions, the floor-plan editor, schedule and policy editors, reports, guest self-service link entry, payments and SMS — are listed as text on the landing, not hidden behind fake screens.
- During the pilot no email or SMS sends anywhere, so demo bookings produce no messages either.
Next steps
- What is DineGlobe — the product and its pilot posture.
- Roles & what they can do — what each demo role may do, and what denial looks like.
- Glossary — the terms used on the board and in the booking flow.