Chowly Pre-Onboarding Wizard — Product Requirements Document

Draft v0.1 — 2026-03-10

1. Problem Statement

Chowly's Call 1 onboarding takes ~2 hours per logo, dominated by information collection, credential gathering, and education — tasks a restaurant operator could complete asynchronously. When operators miss calls, don't have the right person on the line, or can't provide credentials, the entire onboarding timeline slips. Current metrics:

Root causes of slippage: Operators missing calls, wrong contact on the call (need IT/marketing person), missing credentials, website design iteration loops.

2. Solution Overview

A standalone, branded pre-onboarding wizard sent to the customer immediately post-contract signing. The operator (and their team) fills it out before Call 1, so the onboarding team arrives with credentials validated, access granted, and discovery complete.

Incentive: 1-2 month platform credit for completing the wizard pre-Call 1.

3. Onboarding Structure (Current)

Call Flow

Team

• CSM (Customer Success Manager) — drives conversation, handles objections
• TAM (Technical Account Manager) — collects credentials, walks through technical setup
• Calls run as CSM+TAM duo

Current Flow: Contract → Wizard Window → Call 1

1. Sales rep closes deal in Salesforce → PandaDoc signed → Opp closed-won
2. Sales adds handoff notes to Salesforce opportunity
3. Calendly link sent to operator to schedule Call 1
4. 2-7 day gap between close and Call 1 ← wizard fills this gap
5. Call 1 happens

4. What the Wizard Collects (Call 1 Milestones)

4.1 Team & Contacts Discovery

• [ ] Primary contact for onboarding (name, email, phone/SMS)
• [ ] Primary contact for long-term relationship
• [ ] Additional contacts (IT person, marketing person, etc.)
• [ ] Ability to forward/share the wizard link to other team members
• [ ] SMS-capable phone numbers for each contact (used for website change approvals + support texting)

4.2 Logo & Location Structure

• [ ] Logo (brand) name
• [ ] Number of locations
• [ ] Per location: name, address, phone
• [ ] Whether logins are shared across locations or per-location

4.3 Point of Sale (POS) Access

• [ ] Which POS system? (Toast, Square, Clover, other — specify)
• [ ] Admin-level login credentials (username + password)
• [ ] If Toast: Walk through creating a user at auth.toasttab.com
• [ ] If Square: Walk through creating a user at squareup.com/dashboard
• [ ] Other POS: Generic SOP link for creating admin user
• [ ] Install Chowly app in POS backend (if applicable)
• [ ] Credential validation: attempt login to verify before saving
• [ ] Credentials stored using email format: access+{logoname}@chowlyinc.com

4.4 Third-Party Marketplace Access (3POS)

For each platform the operator uses:

DoorDash (merchant portal: doordash.com/merchant) - [ ] Username + password - [ ] Create/invite Chowly user - [ ] Credential validation

Uber Eats (restaurant.uber.com) - [ ] Username + password - [ ] Create/invite Chowly user - [ ] Credential validation

Grubhub (merchant.grubhub.com) - [ ] Username + password - [ ] Create/invite Chowly user - [ ] Credential validation

Per location: customer-facing menu links (to map locations to marketplace pages)

4.5 Payment Processing

• [ ] Toast POS → auto-opted into Toast payments (no setup)
• [ ] Square POS → auto-opted into Square payments (no setup)
• [ ] All other POS → Stripe Connect onboarding required (linked to launch.me entity — may not be automatable in v1 since entities aren't created yet)

4.6 Domain & Registrar Access

• [ ] Current website URL / domain name
• [ ] Need Chowly to purchase a domain? (Y/N)
• [ ] Registrar (GoDaddy, Squarespace, Namecheap, etc.)
• [ ] Auto-WHOIS lookup if operator doesn't know registrar
• [ ] Registrar login credentials OR invite Chowly as user
• [ ] Purpose: CNAME cutover to Chowly-hosted site on Cloudflare

4.7 Google Business Profile (GBP)

• [ ] Per location: street address → auto-lookup GBP
• [ ] Operator confirms: is this their GBP listing?
• [ ] Are they owner or manager of the GBP?
• [ ] Can they invite Chowly's group ID as manager?
• [ ] If no access: who does have access? (capture contact)

4.8 Google Ads Discovery

• [ ] Currently running Google Ads? (Y/N)
• [ ] Have an existing Google Ad account? (Y/N)
• [ ] Note: Chowly typically creates a default GSA account pre-Call 1 — wizard can capture discovery but full setup happens later

4.9 Entity / Legal Information

Per entity (may differ by location): - [ ] Entity type (LLC, C-Corp, LP, etc.) - [ ] Legal entity name - [ ] Legal entity address - [ ] Registered agent / owner name - [ ] Owner email + phone - [ ] EIN - [ ] DUNS number (Dun & Bradstreet) — needed for iOS app / Apple Developer account

Used for: Google Ad account verification, toll-free number registration (surveys), Apple Developer account creation

4.10 Mobile App Discovery

• [ ] Current iOS app? (Y/N) → app name, who built it
• [ ] Current Android app? (Y/N) → app name, who built it
• [ ] Have an Apple Developer account? (Y/N)
• [ ] Categories: Self-built (~20%), third-party built like ChowNow (~30%), no apps (~50%)

4.11 Email Marketing Discovery

• [ ] Currently doing email marketing? (Y/N)
• [ ] In-house, agency, or tool (MailChimp, etc.)?
• [ ] Have an email contact list to export/upload? (file attachment)

4.12 Loyalty Program Discovery

• [ ] Currently running a loyalty program? (Y/N)
• [ ] Through POS or third-party? (which company?)
• [ ] Sign-up method: email-based or phone-based?
• [ ] Points ratio (e.g., 10:1 or 1:1)
• [ ] Offering sign-up bonuses?
• [ ] Reward structure details
• [ ] Can they export current loyalty members? (file attachment with members + point balances)
• [ ] Chowly loyalty = phone-based, 1:1 points:dollars, integrates with Toast/Square POS or standalone

4.13 RCC (Restaurant Control Center) Invitation

• [ ] Collect email addresses for all team members who need RCC access
• [ ] Explain what the RCC is and its value
• [ ] Actual invite may be triggered later once entities are created in Chowly systems

5. Product-to-Data Mapping

6. Wizard UX Requirements

Structure

• Logo-level sections: Team/contacts, entity info, email marketing, website, mobile apps, RCC
• Location-level sections: POS, marketplaces, GBP, surveys, loyalty (with "same for all locations" shortcut)
• Branching logic: POS type determines credential flow; marketplace usage determines which sections appear
• Multi-user: Shareable link — operator can forward to IT/marketing person to fill their sections
• Progress tracking: Internal team can view completion %, whether link was opened, per-section status

Trust & Education

• ROI recap from sales handoff notes (personalized)
• Tooltips explaining why each piece of info is needed + which product it enables
• Chowly credibility callouts (10 years, 15,000+ restaurants)
• Mini SOPs with screenshots/links for creating users in POS/marketplace portals
• "Click here for more info" expandable sections

Validation & Smart Features

• Credential validation: Attempt login to POS/marketplace portals to verify before saving
• WHOIS lookup: Auto-detect registrar from domain name
• GBP lookup: Auto-find Google Business Profile from address
• File uploads: Loyalty member exports, email contact lists

Internal Features

• Dashboard showing all active wizards across logos
• Per-wizard: completion %, sections done, last activity, days since sent
• Ability for TAM/CSM to view and pre-fill sections
• Notifications when operator completes sections

7. Timing & Distribution

Incentive: 1-2 month platform credit for completing wizard before Call 1.

8. Design & Branding

• Must match Chowly RCC design language (fonts, colors, logos)
• Vision: eventually lives inside the RCC
• v1: Standalone app with consistent branding
• TODO: Log into RCC to capture design system (colors, fonts, component styles)

9. Open Questions

1. Credential validation: How deep can we go? Can we actually test POS/marketplace logins, or just format validation? (Security/legal implications of automated login)
2. Stripe Connect: Can't generate links until entities exist in launch.me — defer to post-Call 1, or find a way to create entities earlier?
3. RCC invites: Same — can't invite until entities exist. Wizard captures emails, actual invite is manual/later.
4. Apple Developer account: Complex flow — worth including a guided walkthrough, or better as a Call 2/3 item?
5. Security: Wizard collects POS passwords, marketplace passwords, EINs. What's the security model? Encryption at rest, access controls, retention policy?
6. Data destination: Where does collected data flow? Directly into 1Password? Into Salesforce? Into a Chowly internal tool?
7. Tech stack: Build custom (React app on Cloudflare Pages)? Use a form platform (Typeform, Fillout, etc.)? Something else?
8. Salesforce integration: Should wizard creation be triggered automatically from Closed-Won in Salesforce?
9. PandaDoc overlap: PandaDoc already collects some info at contract signing — any overlap to eliminate?

10. Next Steps

• [ ] Research: How top SaaS companies handle pre-onboarding (Rippling, Gusto, HubSpot, etc.)
• [ ] Review Chowly Confluence docs tagged "Onboarding" for SOPs and current processes
• [ ] Log into RCC to capture design system
• [ ] Scan chowly.com for product/value prop language
• [ ] Decide on tech stack (custom build vs. form platform)
• [ ] Prioritize: What's v1 (MVP) vs. v2?
• [ ] Map credential validation feasibility per platform