A
Cutover PortalRestaurant

Make go-live boring.

This is the implementation cockpit for the free trial and the launch calendar. It shows the work that starts immediately, the proof a restaurant should see in seven days, and the data habits that mature after cutover.

Go-live phase

Apr 28, 2026

Day 63 of adoption

Post-Cut

Readiness

28%

12

ready

30

verify

1

blocked

Start the slow work first

5 long-lead tracks + launch calendar · click any card to expand

Helper shift board

This is the onsite portal for Holly or any cutover helper. Start a step, mark it done, flag help, leave notes, and package the context for Maestro/Orion so support can see what happened.

Today's rule

Fix blockers during service, capture everything else. A note with a step is better than a memory at midnight.

0

active

0

done

0

help

16

open

Syncing cutover plan

Orion cutover bundle

Using the canonical restaurant cutover bundle with local fallback.

Bundle fallback

Human checkpoint

Menu accuracy and descriptions

Names, prices, modifiers, availability, and descriptions must be verified by the restaurant.

Next recommended

Work the first open day-one step

AIR keeps the ordered bundle below as the active cutover plan.

Plan profile

standard · canonical steps

If Orion cannot map the restaurant project, AIR keeps using the local bundle cache.

Day-one blockers

Must finish

Pre-cut · AIR

Open

Pre-cut · AIR

Open

Pre-cut · AIR + owner

Open

Pre-cut · AIR + manager

Open

Pre-cut · AIR + host

Open

Pre-cut · AIR + owner

Open

Pre-cut · AIR

Open

Pre-cut · AIR + manager

Open

Pre-cut · Manager + server

Open

Pre-cut · AIR + owner

Open

First-week adoption

Active after cut

Pre-cut to post-cut · AIR + manager

Open

Post-cut · GM

Open

Data maturity

Needs data

Post-cut · Owner + kitchen lead

Open

Post-cut · Kitchen manager

Open

Post-cut · Owner + AIR marketing

Open

Post-cut · Owner + AIR

Open

Priority weighting

This keeps the cutover honest. Not every important feature deserves the same urgency before the first service.

Day-one blockers

Highest

If this fails, the restaurant cannot safely serve customers on AIR.

Payments and terminalsKitchen tickets and receiptsPWA order entryFloor map/table flowRollback path

First-week adoption

High

If this is weak, staff can go live but the owner will not feel AIR helping yet.

Joe shadow modeTexting readinessLoyalty/review QRSettings confidenceManager station habits

30/60/90-day value

Planned

These are huge value drivers, but they need data habits before they deserve cutover-level urgency.

Recipes and invoicesPlate cost confidenceInventory controlsMarketing automationCFO intelligence

Readiness matrix

Each stream rolls up launch status and keeps the detailed checks one tap away.

Public Customer Flows

A guest can find the restaurant, order pickup, join the waitlist, and reserve without staff intervention.

5 verify

Owner: Website / checkout

Customer website

Public domain is live; verify the final v2 route after the flip.

Verify

Pickup ordering

Menu and checkout tested locally; run one live Square smoke after deploy.

Verify

Reservations

Built in v2 with availability checks; production route waits on v2 deploy.

Verify

Waitlist QR

Public waitlist flow exists; scan from a server phone before service.

Verify

Loyalty lookup

Phone-order loyalty prompt is wired; customer SMS depends on approved texting path.

Verify

POS and Service Flow

Staff can take real orders quickly, correct mistakes, and move tables through service.

4 verify

Owner: PWA / iPad / server phone

Order entry

Tap table, add items, modifiers, spice levels, and notes.

Verify

Server phone mode

Mobile PWA exists; run one phone order-entry pass before flip.

Verify

Payments and close

Run card, tip, auth slip, receipt, and return-to-map as one full path.

Verify

Manager controls

Void, comp, reopen, and issue notes should require the expected authority.

Verify

Floor Map and Seating

The map in AIR matches how the dining room actually works during a rush.

1 ready4 verify

Owner: Tables / sections / host stand

Floor plan source

Future onboarding should accept a photo, screenshot, or existing POS map as the starting point.

Ready

Table inventory

Every real table needs number, capacity, shape, and active/inactive state.

Verify

Server sections

Sections should be assigned before training so staff sees their real floor.

Verify

Reservation seating

Reservations and waitlist need the same table IDs the POS uses.

Verify

Mobile map sanity

Server phone view should show the same room without forcing staff to pinch and hunt.

Verify

Payments and Terminals

A restaurant can take cards, adjust tips, print slips, and reconcile without thinking about the processor.

5 verify

Owner: Square / Stripe / card hardware

Processor decision

Square is the default restaurant path; Stripe stays available where it fits the account.

Verify

Live credentials

API keys, location ID, webhook URLs, and return URLs must be production-ready before flip.

Verify

Terminal inventory

Each terminal needs a name, location, pairing status, and test charge result.

Verify

Tip and auth slip flow

Run card auth, printed tip checkboxes, tip adjust, capture, and customer receipt end to end.

Verify

Refund and void path

Manager needs a rehearsed path for bad tests, duplicate charges, and customer fixes.

Verify

Printers and Hardware

Tickets print in the right place, receipts tear cleanly, and the network has a fallback plan.

2 ready2 verify1 blocked

Owner: Kitchen paper / network hardware

Printer inventory

Known restaurant printers are in the v2 database and visible in the console.

Ready

Web printing primary

Primary launch path; test kitchen ticket, receipt, and auth slip from the iPad.

Verify

Pi backup

Decide whether the restaurant needs a Pi, then bring it onsite and test before relying on it.

Blocked

Receipt design

Tip checkboxes, cut-feed padding, and receipt copy settings are in v2.

Ready

Broadcast and channel routing

Confirm dine-in, phone, online, DD, UE, and GH ticket routing rules.

Verify

Phone AI and Messaging

Joe can answer, order, reserve, hand off, and text without confusing the restaurant numbers.

4 ready2 verify

Owner: Joe / Twilio / ElevenLabs

Published voice number

(540) 216-5800 is the customer-facing Joe number.

Ready

AIR texting number

+1 833-324-7207 is reserved for texting and customer SMS.

Ready

Staff transfer number

(540) 326-4514 is the private restaurant DID for handoffs.

Ready

Phone menu exclusions

Lunch and happy-hour exclusions are handled separately from dine-in.

Ready

Launch QA trio

Run ElevenLabs voice test, browser test, and resolver QA before turning on.

Verify

Day 8 tune-up

After one week of ambient listening and phone transcripts, run deep QA and propose aliases, menu cleanup, and upsells.

Verify

Restaurant Settings and Integrations

All configuration work is visible, auditable, and eventually controllable from the owner chat surface.

1 ready4 verify

Owner: Settings / KitchenHub / Orion

Core restaurant settings

Taxes, tips, auto-grat, receipt policy, roles, permissions, hours, channels, and service defaults.

Verify

KitchenHub and delivery platforms

DoorDash, Uber Eats, Grubhub, and KitchenHub routing need credentials, provider confirmation, menu/hour sync, channel rules, and print routing.

Verify

API keys and Orion access

Owners can issue AIR-MCP keys and connect Anthropic/Claude surfaces to AIR and Orion-backed configuration.

Verify

AI change approval

Default path should be propose, review, approve; power users can opt into automatic changes later.

Ready

Audit trail

Configuration changes from chat, dashboard, or staff tools need to be visible in one activity trail.

Verify

Data and Operator Adoption

New customers get to operational quickly without drowning in setup details.

4 ready1 verify

Owner: Setup data / training

Menu import

Use the 80-90% fast path from the 99-step audit; polish after launch.

Ready

Real staff and hardware data

Staff, printer, table, and phone data are real enough for launch testing.

Ready

Operator guide

Day-1 workflow exists at /home/guide and should stay linked from cutover.

Ready

Cutover portal

This page becomes the repeatable implementation cockpit for each restaurant.

Ready

Post-launch learning loop

Ambient listener runs 1-2 weeks, then aliases and workflow gaps get promoted.

Verify

Post-Cut Growth and Controls

After the restaurant is live, AIR keeps getting smarter from the data owners enter every week.

3 verify2 later

Owner: Recipes / invoices / reputation / marketing

Recipe entry

Owners enter real recipes, prep yields, portions, and substitutions for the first 30 days.

Verify

Invoice capture

Vendor invoices need to be entered or photographed consistently before plate cost is trusted.

Verify

Plate cost confidence

COGS and margin guidance become useful after recipes and invoice pricing have enough history.

Later

Reputation and loyalty

Receipt QR, review gate, loyalty enrollment, and reorder links become the retention engine.

Verify

Google and social automation

Marketing automation should start after the site, menu, reviews, and offer rules are stable.

Later

Owner / restaurant tasks

  • Bring the Pi onsite and connect it to the restaurant network.
  • Confirm every payment terminal that should be live on day one.
  • Share the existing floor map, table list, or a clear photo of the dining room layout.
  • Confirm the private staff transfer DID and who answers it during service.
  • Confirm Square live account behavior for pickup checkout and refunds.
  • Have one manager and one server run the iPad and phone PWA flows.
  • Confirm the restaurant's third-party delivery plan, including Shipday, KitchenHub, and any DoorDash/Uber Eats/Grubhub POS-change steps in the provider merchant portals.
  • Commit to 30 days of recipe and invoice entry before trusting plate-cost automation.
  • Choose who owns AIR-MCP/API keys and who approves AI-proposed configuration changes.
  • Choose who approves Google, social, SMS, and offer automation after launch.

AIR tasks

  • Deploy v2 and verify channara.net routes after the flip.
  • Pair and test payment terminals with live processor credentials.
  • Build and QA the floor map, sections, table capacities, and reservation seating.
  • Configure restaurant settings, integrations, Shipday delivery rules, KitchenHub scope, marketplace provider status, and API key guardrails.
  • Run the public customer smoke suite before customers are sent to the site.
  • Run printer, receipt, and auth slip tests from the actual restaurant network.
  • Keep Joe in ambient/shadow mode until the required QA and texting path are ready.
  • Turn recipes, invoices, reviews, loyalty, and marketing into a 30/60/90-day adoption plan.
  • Push launch findings into Orion as reusable cutover patterns.

Launch sequence

The order matters. Test customer-visible paths first, then the restaurant floor, then the paper and recovery paths.

1

Pre-flight

Before domain flip

  • Run public website, order, reservation, waitlist, loyalty, and phone-link smoke tests.
  • Run PWA order entry from iPad and phone against a real table and a fake to-go order.
  • Print kitchen ticket, receipt, auth slip, and one channel-routed test ticket.
  • Confirm v2 env vars, Twilio numbers, Square, Neon, and custom-domain routing.
2

Flip

Launch window

  • Point channara.net at the v2 deployment and verify /, /order, /reservations, and /waitlist.
  • Warm the site once on desktop and phone so the first customer does not discover a cold edge.
  • Place one tiny paid Square test, then refund or void according to the processor path.
  • Leave the current production path available as rollback until first service is stable.
3

First service

Opening shift

  • Keep PWA, printers, KDS, Phone AI, and orders visible from the manager station.
  • Log every miss as either training, data, routing, hardware, or UX.
  • Do not chase polish during rush; fix blockers, capture the rest.
  • Run closeout with payments, receipts, tips, comps, voids, and open tickets reviewed.
4

First 1-2 weeks

Learning period

  • Let ambient listener collect real phrases and server corrections.
  • Review phone AI mismatches, printer failures, checkout friction, and staff workarounds.
  • Promote repeat fixes into Orion patterns so the next restaurant starts ahead.
  • Graduate the cutover portal from one-off checklist to reusable onboarding product.

Post-cut operating roadmap

Cutover gets the restaurant live. The next 90 days are where AIR earns trust: Joe learns, food cost gets real, inventory tightens, and marketing starts using actual guest behavior.

T-7 to T+7

Joe Shadow Mode

AIR + manager

Trigger: Texting number and transfer path in progress

Joe activates only after real phrases, menu aliases, handoff rules, and SMS readiness are proven.

  • Run ambient listener for at least one week before activation whenever possible.
  • Run ElevenLabs voice test, browser order test, and resolver QA as the required launch trio.
  • Tie activation to texting readiness, transfer number clarity, and a manager handoff plan.

Day 0 to 30

Food Cost Foundation

Owner + kitchen lead

Trigger: Restaurant is live and daily sales are flowing

Plate cost and margin recommendations start from real recipes and invoices instead of guesses.

  • Enter recipes, portion sizes, prep yields, substitutions, and menu item mappings.
  • Enter or photograph every vendor invoice so unit costs and price changes are captured.
  • Review early plate-cost outliers weekly, but wait for enough data before changing the menu.

Day 30 to 60

Inventory Controls

Kitchen manager

Trigger: Recipes and invoices have a usable 30-day base

AIR can compare theoretical usage, actual purchases, waste, and vendor price movement.

  • Start weekly counts on high-cost items before attempting full-store inventory.
  • Set pars for critical ingredients and flag vendor price jumps.
  • Use waste, comps, voids, and stockouts to tighten recipes and ordering habits.

Day 7 to 30

Retention and Reputation

GM / manager station

Trigger: Receipts and customer links are stable

Review gate, loyalty, reorder links, and manager alerts start creating direct customer memory.

  • Confirm receipt QR flows for review gate, loyalty enrollment, reorder, and private feedback.
  • Send bad-review and Joe issue alerts into the manager station workflow.
  • Watch direct reorder and loyalty enrollment before turning on larger campaigns.

Day 30 to 90

Marketing Automation

Owner + AIR marketing

Trigger: Menu, offers, customer list, and review flow are stable

Google, social, SMS, and direct-order campaigns run from operational truth instead of generic content.

  • Connect Google profile content, review links, website menu, specials, and photo assets.
  • Build a light social calendar around real specials, high-margin items, and events.
  • Turn on SMS/email campaigns only after compliance, opt-in, and offer rules are clear.

Day 30 to 90

Back Office Maturity

Owner / bookkeeper

Trigger: Payments, tips, payroll, purchases, and sales data are consistent

AIR moves from operating system to CFO assistant: labor, tips, purchases, delivery fees, and closeout.

  • Review tips, payroll, schedule accuracy, and labor percentage against real sales patterns.
  • Reconcile payments, deposits, refunds, delivery fees, and bookkeeping exports.
  • Promote monthly insights into owner-facing CFO briefs and next-action recommendations.

Day 0 to 30

Orion Configuration Portal

Owner + AIR

Trigger: API keys and approval policy are in place

Owners can use Claude/Anthropic chat surfaces to ask, configure, and verify AIR changes through Orion-backed tools.

  • Issue AIR-MCP keys and confirm the owner understands scopes, approvals, and revocation.
  • Connect the chat workflow to safe configuration actions first: settings, hours, specials, 86s, prices, and guides.
  • Review audit logs until owner trust is high enough to expand the tool surface.

Current launch truth

channara.net is live on the current AIR-Web production path. AIR-Web v2 is the cutover candidate. The final move is not just a domain flip; it is a verified service rehearsal with customer flows, staff flows, printer paths, Phone AI, and rollback all accounted for.

Other AIR surfaces

Most belong before or after cutover · bookmarked for quick access
99-step auditProduct audit + gapsOperator guideDay-1 manualPOS viewOrder entry rehearsalPrinter consolePrinter routingPhone AIJoe + Twilio QAReservationsBook + waitlistSettingsTaxes, tips, rolesRamp UpPost-cutover features
💼

CFO Assistant

I’m here to help you use your menu as a revenue-generating tool. Before we look at growth opportunities, let’s make sure your data is clean and accurate — that’s the foundation everything else is built on. What would you like to start with, or should I flag what I’m seeing?