Train-the-trainer guide

This page is for whoever will deliver PrepTable training to a campus team. It assumes the role of the trainer (often a Saavor or PrepTable team member on the customer-success side) and outlines a facilitation plan, what to show in what order, and the demo data that powers the experience.

It's structured as a half-day session by role, with the first 30 minutes on overview shared by everyone.

Pre-session checklist (T-7 days)

• [ ] Confirm which campuses will be in scope for the customer's first 90 days
• [ ] Verify the target environment has a fresh seed of demo data (see "Demo data" below)
• [ ] Pull the latest usage stats from the customer's actual environment if migrating from a spreadsheet — those numbers make the inventory session concrete
• [ ] Confirm passkey registration is working for the trainer laptop; WebAuthn on a fresh browser can fail in surprising ways
• [ ] Schedule a 10-minute pre-call with the customer's lead admin to verify kiosk / display hardware

Pre-session checklist (T-1 day)

• [ ] Reset the sandbox environment to a known state (see "Sandbox reset" below)
• [ ] Verify each role's view by signing in as: floor staff, campus manager, admin
• [ ] Generate the day's menu-health check; have its findings open in a tab for the manager session

Session structure

Block 1: Overview (everyone, 30 min)

Order of rooms doesn't matter much; pick the one with a screen.

1. What is PrepTable? (5 min) — the orientation from the Overview section. Stress the Saavor boundary: anything money or order-touching belongs to the POS; PrepTable runs everything before and after the sale.
2. Live walk-through of one campus's day (15 min) — open the app, switch to a campus, walk the morning: low-stock alert, draft PO, mid-shift substitute, end-of-day check.
3. How the kitchen display works (10 min) — show the ticket states, deliberately delay marking one Ready to demonstrate the timer. Have a volunteer "be the cashier" with the trainer playing line cook.

Block 2: Floor staff (30 min, only floor staff)

Most of this is hands-on with the kitchen display.

• Sign in as the floor-staff account on the wall-mounted display.
• Have the trainer (as cashier) ring a real order in Saavor (via test mode); the participant walks it through the four states.
• Run the "what to do when something looks wrong" table from the kitchen-display page. Each row gets a deliberate demo.

If the staff shift is more than four people, the trainer runs the session twice — better retention than one big group.

Block 3: Managers (60 min, only managers)

The heaviest block; this is where most of PrepTable's value lands.

1. Campus scoping demo (10 min) — sign in as a manager with only one campus; show that the switcher offers only that campus; promote to two campuses; show the expanded switcher.
2. Par levels (15 min) — set or adjust par levels for a couple of items; show how the low-stock dashboard responds in real time. Discuss the rounding-up heuristic in the par-levels page.
3. Drafting a PO from shortfall (10 min) — start from the low-stock dashboard, click Draft PO, walk the pre-fill, adjust, send.
4. The menu-health check (15 min) — open the pre-built check from T-1. Walk each of the five findings. Have the manager fix one of them live ("swap Wednesday lunch's chicken recipe for the soup that's been idle for two weeks").
5. Q&A and edge cases (10 min) — usually dominated by "what if the vendor doesn't deliver," "what if I set par too high and we waste," "what about allergens" — refer to the FAQ in the engagement channel.

Block 4: Administrators (45 min, only admins)

Often 1–3 people; frequently the IT lead and a dining-services director.

1. Roles and campus assignment (15 min) — show the user_locations table in the UI; invite a fresh staff account; assign a campus to a manager; show the immediate effect.
2. Audit log (10 min) — make a few live changes (par adjustment, PO draft, role assign); show the diffs in the log.
3. Data export (5 min) — CSV export of usage and low-stock reports. Confirm the business office's tooling can consume them.
4. Kiosk / integrations setup (10 min) — generate a kiosk token, register the wall display. Walk the Saavor webhook configuration.
5. Production safety: seedgen (5 min) — explicitly demonstrate the prod-safety refusal of the seed generator (it's allowed in dev, refused in prod without --force). The point is to make sure no one tries to use the seed tool as a data-loading utility.

Block 5: Wrap (everyone, 15 min)

• Q&A on cross-role concerns (what happens when a manager leaves mid-shift, what happens during a weekend outage, etc.)
• Hand out the printed reference card (suggested content in Appendix A below)
• Schedule the post-session office hours

Demo data

Train on the canonical seed, not production data. The seed is maintained as a SQL file plus a seedgen volume-generator (see the seed-generator design spec for the deterministic shape). Use:

• Two campuses, three items each flagged with different par-status states
• One preferred vendor pricing change in the last 7 days (so the cost-outlier check fires)
• One item above 2× par with no upcoming menu (so use-it-up fires)
• One recipe scheduled 5× in the next 7 days at lunch (dish repetition)

This makes the menu-health check page produce meaningful findings during Block 3.

Sandbox reset

Before each session, the sandbox database is restored from the canonical seed (above) using:

# Re-seed demo data after the previous session's writes.
PGSSLMODE=disable psql -d preptable -f api/seeds/campus_dining.sql

The volume-generator (seedgen) then layers realistic activity on top — inventory movements, waste entries, a few audit rows from the trainer's "fake" admin actions — so the audit log in the admin session has diffs to show.

Do not run seedgen against production. It refuses to run when DATABASE_URL points at a production host unless --force is passed. The error message is deliberately loud; the trainer's job here is to demonstrate this safety net.

Appendix A: Reference card contents

Two sides, laminated, in every trainer's kit:

Side 1 — Where to find things

Need	Where
"I think we're low on X"	PrepTable → Inventory (manager or admin)
"What does this recipe cost?"	PrepTable → Recipes → Plate cost (manager or admin)
"Did the order go to the line?"	Saavor — orders push to PrepTable kitchen display automatically
"How do I change a price?"	Saavor, not PrepTable
"Who changed my par level?"	PrepTable → Admin → Audit log
"I can't see campus Y"	Ask your admin to assign it to you
"This item is unavailable on the menu"	PrepTable → Menus → toggle off (manager only)

Side 2 — When to escalate

Symptom	Escalation path
Kitchen display not loading	Local Wi-Fi / hardware; if persistent, network team
Can't log in	Passkey lost → ask an admin to register a second passkey before revoking the lost one
Menu is wrong for today's service	Campus manager (live menu change)
Vendor pricing is stale	Campus manager (preferred vendor) or admin if no preferred vendor set
Audit log shows an unexpected change	Admin — investigate immediately
Saavor not sending orders	Integration team — Saavor webhook secret may need rotation

Where to go next

• Roles & campus permissions — the access model the admin session deepens
• The audit log — the material the admin session demonstrates