DineGlobeDocs

Manager guide

Set up and run a venue: floor plan, offerings, schedules, policies, imports, reminders, reports, refunds and privacy cases.

Manager

A manager runs one venue end to end: its setup, its service, its guest relationships, its data and its day-to-day money questions. The role is venue-scoped — a manager of one venue has no authority at another venue of the same organization — and it is the working complement to the ownership tier, which keeps the commercial contract (payment account, subscription, refund approvals).

How you get the role

MANAGER is granted by an owner or org admin of the organization; another manager cannot mint one. The grant ceiling matters: a manager may invite and manage only HOST, DOOR and READ_ONLY in their own venue — attempting to grant MANAGER, FINANCE, ORG_ADMIN or OWNER refuses with PERMISSION_DENIED. Assigning a role replaces the member’s single row for that scope and takes effect on the next request. Setup basics: Organizations, teams & invitations. To feel the role first, use the live demo Manager card (“Review the day”).

Sign-in and first screen

Sign in at /app/login; with two-step verification enrolled, a 6-digit code or recovery code is requested. You land on Your venues at /app. Besides the venue board you also see Add a venue — managers hold venues.manage and can create venues under an existing organization (Venues, slugs & publication).

Setup the manager owns

  • Floor plan — areas, resources (tables, booths, seats, bars, private rooms), placements and approved 2–4-resource combinations. The list editor and the layout reads/writes are the keyboard-complete way to do it. See Floor plan & resources.
  • Offerings and schedules — services with approval mode (Instant or Request), party bounds, duration, notice and horizon; the complete weekly schedule set published in one act (weekday 0 = Sunday); and date exceptions for closures and override windows. See Offerings & schedules.
  • Booking policies — versioned, immutable once published: payment mode, deposit basis and amount, free-cancellation minutes, retention rates, grace window and the localized terms text. Editing means retiring and publishing again. See Booking policies & cancellation.
  • Publication — request the venue’s public review when its profile content and at least one active resource are ready; the venue moves to PENDING_REVIEW and stays private until a platform operator approves it. Approval is never self-awarded.

Reservations: the deciding seat

The one reservation power hosts lack lives here: reservations.approve.

  • Decide requests — approve (confirm and allocate) or decline with a reason the guest sees. Approval re-runs every availability check, so a slot that sold out conflicts honestly and you decline instead.
  • Sweep overdue requests — a request expires at the earlier of its 24-hour review deadline and service start.
  • Change bookings — reschedule (with the soft-pacing override reason, which is re-authorized as a manager act server-side), cancel with a quoted policy outcome, mark no-show after the grace window, and run the reconfirmation request/answer pair.
  • Correct arrivals — checkin.correct belongs to managers: set the absolute arrived count with a required reason.

Deep pages: Request-approval bookings, Changing & cancelling, Arrivals, seating & visits.

Guests, privacy and data

  • Guest CRM — search per venue, add encrypted purpose-limited notes (GENERAL, DIETARY, ACCESSIBILITY, ALLERGY), record append-only consent evidence. Guest profiles & notes.
  • Privacy cases — the manager is the privacy officer of their venue dataset: open ACCESS/CORRECTION/DELETION cases, stamp identity verification (a matching email verifies nothing), execute deletion to the lawful minimum, apply and release bounded legal holds, approve and run retention sweeps, and reapply the deletion ledger after a restore. See Privacy, retention & deletion.
  • Bulk data — stage a CSV dry run, then commit it (every row books through the live allocator; a repeated external id can never become a second booking), and render the venue’s FUTURE_BOOKINGS export with a purpose that is audited verbatim. Hosts and door are refused. See CSV import and Service sheet & CSV exports.

Messaging and reminders

Retry a visibly failed message, preview a template (it renders exactly what the guest would receive and sends nothing), and save reminder settings — the SMS switch, the two-hour reminder and quiet hours. Saving a switch is not activation: capability gates decide at dispatch. During the pilot SMS stays gate-closed and email jobs dead-letter visibly with PROVIDER_NOT_CONFIGURED; the failed outcomes show masked recipients. See Messages, confirmations & reminders.

Reports and exports

Render the operational metric report — accepted parties, covers, cancellation split, lead times, waitlist conversion and per-currency money that is never combined across currencies. Metrics that have no instrumented source (POS spend, online booking conversion, demand lost, resource utilization, actual occupancy) are named as unavailable instead of being zero-filled, and zero-denominator rates read “not applicable”. Queue the private service sheet (any service date, unlike the host’s today-only bound) or the metrics CSV. See Reports & metrics and Service sheet & CSV exports.

Money: request, never approve

Managers hold payments.refund.execute and the money read views:

  • Read payment status per reservation — the reservation and payment badges are separate lines, receipts carry the provider’s own effect ids, and a refund pending at the provider reads PENDING, never “Refunded”.
  • List finance transactions — settled rows by transaction date, totals per currency only, plus the pending refund queue.
  • Request refunds — against a reconciled capture, bounded by the refundable balance. At or below the venue’s delegation threshold the intent is born approved; above it (or with no threshold set) it waits for an ownership-tier decision. Both requesting and approving demand MFA verified within the last 30 minutes on your session.

You cannot approve or decline a refund, cannot set the threshold, cannot connect the payment account and cannot touch the subscription — those are ownership-tier acts. See Refunds and Payments (pilot posture).

What a manager cannot do

  • Approve refunds, set the delegation threshold, connect the payment account, or manage billing — all ownership tier (Refunds, Subscription billing).
  • Grant staff above HOST/DOOR/READ_ONLY — the service layer caps the ceiling regardless of what the form offers.
  • Grant org-wide roles or sit on org-wide rows yourself — org-wide authority belongs to OWNER and ORG_ADMIN.
  • See other venues — a venue outside your membership answers a plain 404, never a permission error.
  • Platform operations — publication approvals, capability flags and intake suspension live on a separate platform authority axis (Platform operator console).
  • The audit trail — audit.read is reserved for the ownership tier (and in this release no screen consumes it yet — see What works today & known limits).

Every refusal above is PERMISSION_DENIED (403); codes and fixes are in Error codes & fixes, and account security (sessions, two-step verification, recovery codes) in Your account & security.