Pre-cut · AIR
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
First full day after cutover
Readiness
29%
12
ready
29
verify
1
blocked
Start the slow work first
The free week should make the workload visible. These tracks begin before the owner decides to cut over because approvals and data habits are what usually stretch the calendar.
Start day 0
Texting approval and phone routing
A2P approval, legal pages, Twilio numbers, transfer routing, and Joe QA can take longer than the POS build.
Published voice number, texting number, transfer DID, SMS webhook, and EL/browser/QA tests are all documented.
OpenStart day 0
Recipes and vendor invoices
Plate cost is earned from recipes, portions, yields, substitutions, and real invoice prices.
Top sellers have recipes, invoices are photographed or entered weekly, and early outliers are reviewed without overreacting.
OpenStart day 2
Inventory baseline and shopping lists
Accurate shopping lists need counts, pars, waste notes, vendor units, and supplier price movement.
High-cost items have a count, par, vendor unit, recipe link, and first shopping-list suggestion.
OpenStart day 0
Payments and terminals
Processor credentials, devices, tips, auth slips, refunds, and closeout need live-mode proof before service.
Test charge, tip adjust, receipt/auth slip, refund/void, and end-of-shift reconciliation all pass.
OpenStart during trial
Delivery and KitchenHub
Third-party channels need credentials, menu visibility, price rules, source labels, and printer routing.
Each channel has a routing rule, menu availability policy, source label, and smoke-tested ticket.
Open7-day trial to launch calendar
The free week is not a toy demo. It is the calendar that shows what AIR can build quickly, what the owner needs to provide, and which value drivers mature after real service data starts flowing.
1
Trial day 0
AIR + owner
Kickoff and long-lead start
The owner sees the work clearly and the slowest approval/data tracks start immediately.
- Set target go-live date, launch scope, owner contacts, and decision criteria for the free week.
- Upload menu, current POS exports, floor map photo, staff list, printer list, processor info, and delivery/KitchenHub notes.
- Start SMS/A2P, phone routing, payment terminal, recipes, invoices, and inventory baseline work before polish begins.
2
Trial days 1-2
AIR
Core POS proof
AIR looks like the restaurant and a manager can tell whether the setup burden feels reasonable.
- Build menu, modifiers, category order, channel availability, phone exclusions, taxes, tips, and receipt defaults.
- Seed staff, roles, permissions, table map, sections, printer inventory, and restaurant settings.
- Run a first order-entry pass so owner can compare AIR setup effort against a traditional POS cutover.
3
Trial days 3-4
AIR + restaurant
Customer paths and service flow
The public flows and staff flows are real enough to test from phones, iPads, and the host stand.
- Smoke website, pickup ordering, reservations, waitlist QR, loyalty/review QR, and customer phone links.
- Run iPad and server-phone order entry with modifiers, spice levels, notes, comps, voids, and closeout.
- Run printer routing, receipt design, auth slip, cut-feed padding, and payment terminal tests.
4
Trial day 5
Owner + kitchen lead
Food-cost and inventory habits
The owner understands which intelligence features need operating data instead of launch-day promises.
- Enter recipes for top sellers with portion size, prep yield, substitutions, and menu-item mapping.
- Photograph or enter vendor invoices so unit costs, pack sizes, and vendor price changes start accumulating.
- Count high-cost inventory items, set starter pars, and generate the first draft shopping-list rules.
5
Trial day 6
AIR + owner
Joe, channels, and manager station
The owner sees what is ready now, what needs shadow mode, and what should wait for real data.
- Run Phone AI voice test, browser order test, resolver QA, transfer test, and phone menu exclusion checks.
- Confirm delivery/KitchenHub plan, source-channel printing, online menu availability, and manager alerts.
- Review where bad reviews, Joe issues, late orders, and printer failures should appear for managers.
6
Trial day 7
AIR + manager
Trial decision and launch calendar
The restaurant can make a calm go/no-go decision and put the remaining work on a calendar.
- Review what passed, what blocked, what needs owner credentials, and what should move to 30/60/90-day data maturity.
- Pick launch date, rehearsal date, staff training date, terminal/printer test date, and first recipe/invoice review date.
- Freeze launch scope so the cutover feels like a normal POS switch, not 15 software products landing at once.
7
After yes
AIR + restaurant
Build, rehearse, and flip
The calendar turns trial findings into a launch plan with rehearsal, rollback, and post-cut adoption.
- Finish long-lead approvals and credentials while AIR polishes menu, table map, settings, channels, printers, and payments.
- Run one fake service, one public customer smoke, one printer/payment drill, and one go/no-go review before the domain flip.
- After launch, run ambient listening, recipes, invoices, inventory counts, review/loyalty, and marketing on the 30/60/90-day track.
Action board
These are the cutover steps that should become real restaurant tasks. Mark finished work done, flag help when stuck, and use the context panel to hand the step to an agent or Claude/Orion session.
0
done
0
help
12
open
Day-one blockers
Must finishPriority weighting
This keeps the cutover honest. Not every important feature deserves the same urgency before the first service.
Day-one blockers
HighestIf 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
HighIf 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
PlannedThese 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
Public Customer Flows
A guest can find the restaurant, order pickup, join the waitlist, and reserve without staff intervention.
Owner: Website / checkout
Customer website
Public domain is live; verify the final v2 route after the flip.
Pickup ordering
Menu and checkout tested locally; run one live Square smoke after deploy.
Reservations
Built in v2 with availability checks; production route waits on v2 deploy.
Waitlist QR
Public waitlist flow exists; scan from a server phone before service.
Loyalty lookup
Phone-order loyalty prompt is wired; customer SMS depends on approved texting path.
POS and Service Flow
Staff can take real orders quickly, correct mistakes, and move tables through service.
4 verify
POS and Service Flow
Staff can take real orders quickly, correct mistakes, and move tables through service.
Owner: PWA / iPad / server phone
Order entry
Tap table, add items, modifiers, spice levels, and notes.
Server phone mode
Mobile PWA exists; run one phone order-entry pass before flip.
Payments and close
Run card, tip, auth slip, receipt, and return-to-map as one full path.
Manager controls
Void, comp, reopen, and issue notes should require the expected authority.
Floor Map and Seating
The map in AIR matches how the dining room actually works during a rush.
1 ready4 verify
Floor Map and Seating
The map in AIR matches how the dining room actually works during a rush.
Owner: Tables / sections / host stand
Floor plan source
Future onboarding should accept a photo, screenshot, or existing POS map as the starting point.
Table inventory
Every real table needs number, capacity, shape, and active/inactive state.
Server sections
Sections should be assigned before training so staff sees their real floor.
Reservation seating
Reservations and waitlist need the same table IDs the POS uses.
Mobile map sanity
Server phone view should show the same room without forcing staff to pinch and hunt.
Payments and Terminals
A restaurant can take cards, adjust tips, print slips, and reconcile without thinking about the processor.
5 verify
Payments and Terminals
A restaurant can take cards, adjust tips, print slips, and reconcile without thinking about the processor.
Owner: Square / Stripe / card hardware
Processor decision
Square is the default restaurant path; Stripe stays available where it fits the account.
Live credentials
API keys, location ID, webhook URLs, and return URLs must be production-ready before flip.
Terminal inventory
Each terminal needs a name, location, pairing status, and test charge result.
Tip and auth slip flow
Run card auth, printed tip checkboxes, tip adjust, capture, and customer receipt end to end.
Refund and void path
Manager needs a rehearsed path for bad tests, duplicate charges, and customer fixes.
Printers and Hardware
Tickets print in the right place, receipts tear cleanly, and the network has a fallback plan.
2 ready2 verify1 blocked
Printers and Hardware
Tickets print in the right place, receipts tear cleanly, and the network has a fallback plan.
Owner: Kitchen paper / network hardware
Printer inventory
Known restaurant printers are in the v2 database and visible in the console.
Web printing primary
Primary launch path; test kitchen ticket, receipt, and auth slip from the iPad.
Pi backup
Decide whether the restaurant needs a Pi, then bring it onsite and test before relying on it.
Receipt design
Tip checkboxes, cut-feed padding, and receipt copy settings are in v2.
Broadcast and channel routing
Confirm dine-in, phone, online, DD, UE, and GH ticket routing rules.
Phone AI and Messaging
Joe can answer, order, reserve, hand off, and text without confusing the restaurant numbers.
4 ready1 verify
Phone AI and Messaging
Joe can answer, order, reserve, hand off, and text without confusing the restaurant numbers.
Owner: Joe / Twilio / ElevenLabs
Published voice number
(540) 216-5800 is the customer-facing Joe number.
AIR texting number
+1 833-324-7207 is reserved for texting and customer SMS.
Staff transfer number
(540) 326-4514 is the private restaurant DID for handoffs.
Phone menu exclusions
Lunch and happy-hour exclusions are handled separately from dine-in.
Launch QA trio
Run ElevenLabs voice test, browser test, and resolver QA before turning on.
Restaurant Settings and Integrations
All configuration work is visible, auditable, and eventually controllable from the owner chat surface.
1 ready4 verify
Restaurant Settings and Integrations
All configuration work is visible, auditable, and eventually controllable from the owner chat surface.
Owner: Settings / KitchenHub / Orion
Core restaurant settings
Taxes, tips, auto-grat, receipt policy, roles, permissions, hours, channels, and service defaults.
KitchenHub and delivery platforms
DoorDash, Uber Eats, Grubhub, and future KitchenHub routing need credentials, channel rules, and print routing.
API keys and Orion access
Owners can issue AIR-MCP keys and connect Anthropic/Claude surfaces to AIR and Orion-backed configuration.
AI change approval
Default path should be propose, review, approve; power users can opt into automatic changes later.
Audit trail
Configuration changes from chat, dashboard, or staff tools need to be visible in one activity trail.
Data and Operator Adoption
New customers get to operational quickly without drowning in setup details.
4 ready1 verify
Data and Operator Adoption
New customers get to operational quickly without drowning in setup details.
Owner: Setup data / training
Menu import
Use the 80-90% fast path from the 99-step audit; polish after launch.
Real staff and hardware data
Staff, printer, table, and phone data are real enough for launch testing.
Operator guide
Day-1 workflow exists at /home/guide and should stay linked from cutover.
Cutover portal
This page becomes the repeatable implementation cockpit for each restaurant.
Post-launch learning loop
Ambient listener runs 1-2 weeks, then aliases and workflow gaps get promoted.
Post-Cut Growth and Controls
After the restaurant is live, AIR keeps getting smarter from the data owners enter every week.
3 verify2 later
Post-Cut Growth and Controls
After the restaurant is live, AIR keeps getting smarter from the data owners enter every week.
Owner: Recipes / invoices / reputation / marketing
Recipe entry
Owners enter real recipes, prep yields, portions, and substitutions for the first 30 days.
Invoice capture
Vendor invoices need to be entered or photographed consistently before plate cost is trusted.
Plate cost confidence
COGS and margin guidance become useful after recipes and invoice pricing have enough history.
Reputation and loyalty
Receipt QR, review gate, loyalty enrollment, and reorder links become the retention engine.
Google and social automation
Marketing automation should start after the site, menu, reviews, and offer rules are stable.
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 KitchenHub if needed.
- 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, KitchenHub scope, 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
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
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
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
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
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
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
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.