# Demo scenarios — required proof points and data needs The customer published five scenarios and required that vendors demonstrate **all five thoroughly within the allotted time**. Each bullet below is a customer-stated requirement — treat every one as a scoring line item. If the demo data cannot support a bullet, that bullet cannot be shown. **Verify the agenda against the live working document before every run** — timings and owners change. ## Agenda as of last read (90 minutes, remote Teams) | Time | Segment | Owner | |---|---|---| | 5 min | Introductions, Welcome, Objectives, Agenda | Microsoft | | 5 min | Set Context — value, governance, scalability | Microsoft | | 15 min | **Scenario 1: Lead-to-Customer Lifecycle** | Microsoft | | 2 min | Value Close | Microsoft | | 15 min | **Scenario 2: OLO Integration & Ownership Preservation** | Lumovy | | 2 min | Value Close | Microsoft | | 15 min | **Scenario 3: Ownership Change & Sales Credit Governance** | Microsoft / Lumovy | | 2 min | Value Close | — | | 15 min | **Scenario 4: Hierarchy, Dedupe, Data Governance** | Lumovy | | 2 min | Value Close | Microsoft | | 15 min | **Scenario 5: CSM Productivity, Leadership Visibility** | Microsoft | | 10 min | Closing & Next Steps | — | Each scenario has only **15 minutes**. Data must let the presenter jump straight to the proof point — no hunting, no empty views, no "imagine that…". --- ## Scenario 1 — Lead-to-Customer Lifecycle **Context (customer's words):** a new catering prospect submits an inquiry through an online form (and live) and eventually places their first order. ### Must demonstrate - Lead creation — **manual and automated** - **Automatic ownership assignment** - **Duplicate detection before lead creation** - Lead qualification process - Follow-up reminders and activity tracking - Quote management - Lead conversion to customer - **Sales credit assignment** based on ownership and qualifying activities - How ownership rules are configured - What qualifies as a sales activity - How duplicate records are prevented - What auditability exists across the lifecycle ### Data required - 1 fresh **unworked lead** from a web form (arrives during demo, or pre-staged) - 1 **near-duplicate** existing record to trigger detection on create - Lead assignment rule targeting a CSM by geography - Qualified lead → opportunity → **quote with line items** → conversion path - Activity trail: phone call, email, task, appointment — with **completed** and **open** examples - Audit history enabled on the affected records --- ## Scenario 2 — OLO Integration and Ownership Preservation **Context:** a CSM creates and works a lead; **before conversion**, the prospect places an order through Olo. ### Must demonstrate - Olo order ingestion - **Matching the order to the existing lead** - Automatic conversion to customer - **Ownership preservation** through conversion - **Attribution preservation** - Prevention of duplicate customer creation - Visibility into order history - What matching logic is used - **What happens if multiple records match** - How ownership is maintained through conversion ### Data required - A **worked lead** with real activity history, owned by a named CSM - An **inbound Olo order** payload matching that lead on email/phone - A **deliberate multi-match case** — two candidate records that both plausibly match, to show the exception path (customer explicitly asks about this) - Post-conversion account with **order history visible** and the original owner intact - Attribution/source field preserved end-to-end --- ## Scenario 3 — Ownership Change and Sales Credit Governance **Context:** two CSMs claim ownership of the same customer account after significant activity and a recent sale. ### Must demonstrate - Ownership change requests - Approval workflow, including **multi-level approvals** - Sales credit calculations - **Handling orders placed before approval** - Audit trail and approval history - In-system logging of decisions - How flexible approval workflows are - Customization of attribution rules - How ownership disputes are resolved and reported ### Data required - 1 contested account with **two CSMs** who both have logged activity against it - Activity volume on **both** sides so the credit split is genuinely arguable - A **closed/won order dated before** the ownership change request — the "who gets credit" moment - Pending ownership-change request record + approver chain (2 levels) - Audit/approval history populated - An ownership/attribution report or view to close on --- ## Scenario 4 — Customer Hierarchy, Duplicate Management, Data Governance **Context:** a **large healthcare system** with multiple facilities, contacts, and duplicate records created through multiple ordering channels. ### Must demonstrate - Parent-child account hierarchy - Multiple locations and contacts - Duplicate identification - Merge recommendations - **Configurable survivor rules** - Merge approvals - Full merge audit trail - Required account data validation - **How many hierarchy levels are supported** - **Can ownership differ by location** - What merge controls and **rollback** capabilities exist ### Data required - A healthcare parent account with **3+ child facility accounts**, ideally **3 levels deep** to answer the depth question concretely - **Different owners on different child accounts** — proves ownership can vary by location - Contacts spread across facilities - **2–3 genuine duplicate pairs** created via *different channels* (web, Olo, ezCater) with conflicting field values so survivor rules visibly matter - At least one duplicate with a **better-quality newer record vs. older record with more history** - An account missing required fields, to show validation --- ## Scenario 5 — CSM Productivity and Leadership Visibility **Context:** a CSM begins their day while leadership prepares for a monthly business review. ### Must demonstrate — CSM view - Dashboard / homepage - Customer insights - **Lapsing account alerts** - Follow-up tasks - **Outlook activity capture** - Manual activity logging ### Must demonstrate — Leadership view - Pipeline reporting - Revenue reporting - **Ownership reporting** - Lifecycle reporting ### Also answer - What dashboards are available **out of the box** - What reporting **requires customization** - How inactive accounts are identified and managed ### Data required - A CSM with a **realistic full day**: 5–10 open tasks, overdue and due-today mixed - Enough pipeline **breadth and age** for dashboards to look credible, not sparse - **Lapsed accounts** — no activity in 90/180 days — to trigger alerts - **Closed-won history across several months** so revenue and trend charts have shape - Opportunities distributed across stages, owners, and close dates - Ownership spread across multiple CSMs so ownership reporting is meaningful --- ## Cross-cutting: Integrations The customer separately requires demonstration of: - **Olo → CRM** integration - **Outlook** integration - **Marketing / personalization** integrations: **Braze, Dynamic Yield, Paytronix, Amplitude** Data implication: accounts and contacts should carry plausible **loyalty IDs (Paytronix)**, **campaign/engagement signals (Braze)**, and **source attribution** so these integrations have something to point at rather than being described abstractly. --- ## Dataset design principles for this demo 1. **Every required bullet needs a record.** Walk the bullet list, not your intuition. 2. **Depth beats breadth.** A few accounts with rich history demo far better than many empty ones. 3. **Dates must be relative to demo day.** Overdue tasks must be actually overdue; recent orders actually recent. Re-date if the demo slips. 4. **Deliberate messiness where the scenario needs it.** Scenarios 1, 2, and 4 depend on duplicates and ambiguity existing. A perfectly clean org cannot demo dedupe. 5. **Ownership must be visibly distributed.** Scenarios 2, 3, and 5 all hinge on owner differences. 6. **Name records so the presenter can find them fast** under time pressure.