OpenTable

Setup

On first use, read setup.md and confirm service model, reservation goals, and operating constraints before proposing changes.

When to Use

User needs to operate or improve OpenTable performance for a restaurant, group, or hospitality concept. Agent handles reservation strategy, listing quality, pacing controls, guest communication, and failure recovery. This skill is advisory by default and does not configure authenticated OpenTable automation on its own.

Architecture

Memory lives in ~/opentable/. See memory-template.md for setup and status fields.

~/opentable/
|-- memory.md                 # Current strategy, goals, and integration state
|-- reservation-log.md        # Demand patterns, pacing changes, and outcomes
|-- guest-signals.md          # No-show patterns, special requests, and friction points
`-- incidents.md              # Overbooking, outage, and recovery records

Quick Reference

Use the smallest relevant file for the task.

Data Storage

Local notes stay under ~/opentable/:

• strategy snapshot and current priorities in memory file
• reservation pacing and demand signals in reservation log
• guest behavior patterns in guest signals file
• incident timeline and mitigations in incidents file

Core Rules

1. Anchor Every Change to a Service Goal

Before touching availability or policies, identify the target outcome:

• raise seated covers
• increase average check through better mix
• reduce no-shows and dead inventory
• protect guest experience at peak times

If the goal is unclear, propose options and get confirmation first.

2. Keep Inventory Honest Across All Time Windows

Availability must reflect what operations can actually seat.

• do not open slots that kitchen or floor cannot absorb
• separate peak, shoulder, and off-peak strategy
• treat special events and holidays as explicit override windows

Prefer fewer accurate slots over inflated inventory that leads to walk-back.

3. Use Pacing and Table Mix as Primary Control Levers

Adjust flow with pacing first, not only with blanket block rules.

• map party-size mix by hour
• reserve capacity for high-value windows and turn targets
• adjust release cadence for same-day demand spikes

Never apply broad slot changes without documenting expected impact.

4. Design Guest Messaging to Prevent Friction

Confirmations, reminders, and policy copy should reduce uncertainty.

• keep cancellation windows explicit
• send reminder timing based on lead-time profile
• align special request language with what can actually be delivered

Do not use punitive language when a neutral policy explanation works.

5. Run Weekly Experiments With Measurable Hypotheses

Every optimization cycle must include:

• one hypothesis
• one controlled change
• one measurable result window
• one decision to keep, rollback, or iterate

Avoid stacking many changes in the same week when attribution matters.

6. Prepare Failure Paths Before They Are Needed

For outages, overbookings, and confirmation failures:

• detect quickly with operational signals
• provide fallback booking or waitlist path
• message affected guests with clear options
• log cause, workaround, and prevention action

Reliability and trust beat short-term occupancy gains.

7. Protect Access and Guest Data Boundaries

Use least-privilege access for reservation operations.

• keep account roles scoped to responsibilities
• avoid storing sensitive guest details in long-lived notes
• document only what is required for operational decisions

Never ask users to paste credentials or private account tokens into chat.

Common Traps

• Chasing occupancy without pacing controls -> service collapses during peak turns
• Opening too much inventory early -> high-value demand displaced by low-yield bookings
• Weak reminder and cancellation copy -> avoidable no-shows and support load
• Editing listing content without testing impact -> conversion drops without clear cause
• Ignoring incident postmortems -> repeated failures and reactive firefighting

Security & Privacy

Data that leaves your machine by default:

• none required by this playbook itself

Data that stays local:

• operational notes and decisions stored under ~/opentable/
• local experiment and incident logs without full guest datasets

This skill does NOT:

• configure or execute authenticated OpenTable API access by itself
• request hidden background data collection
• persist credentials in local markdown files
• run undeclared network destinations

Trust

OpenTable workflows depend on OpenTable services and configured integrations. Only install and run this skill if you trust those services with reservation operations.

Related Skills

Install with clawhub install <slug> if user confirms:

• booking - booking workflows and reservation operations in adjacent channels
• customer-support - guest communication quality and service recovery patterns
• analytics - metric design and experiment readouts for operational decisions
• crm - guest segmentation and lifecycle handling beyond single reservations
• travel - broader travel planning context that intersects with dining reservations

Feedback

• If useful: clawhub star opentable
• Stay updated: clawhub sync