Aurora Material Solutions — Demo Script

The word-for-word run of show for the on-site demo, plus what to click and what must be true for each beat to land. Companion to the requirements doc (thesis, personas, constraints) and the runbook (org IDs, reset command).

Audience: Robert Walter (Supply Chain lead, champion) · Angel (CSR manager, the skeptic to win) · likely an IT representative.

The one thing to sell. Robert’s words, verbatim:

“Order entry isn’t our number one problem… really, it’s creating that nucleus that all my orders can go to. And then from the nucleus, it says, well, it goes here, here, here and here.”

Order entry is table stakes. Order landing and routing is the buy decision. Every other vendor leads with extraction. Do not. Lead with the nucleus.

Three numbers to keep saying (his, from the discovery calls):

~20 orders/day entered — 30 min to 2 hr/CSR
50+ orders/day moved — 2+ hr/CSR/day. Movement is the bigger cost.
11 sites, ~9–10 separate ERP instances, 13 CSRs, siloed personal inboxes

Before you start (T-30 min)

Run through the runbook’s pre-flight. The five that actually break the demo:

Signed in, active org Aurora — Order Nucleus (aurora-poc). Any of the 8 site users works now — each carries the manager role in Clerk publicMetadata.roles. See the runbook’s Roles / permissions section for the capabilities that unlocks and how to grant it. (Before 2026-07-27 they were plain members and /team silently redirected them to /inbox.)
The org_aurora_poc Flagsmith segment is ON for all four demo flags (routing card, quote splitting, approval-only, codeless lines).
Staging is serving a build at or after 98a9d319d (#2652 — routing card + split-to-site routing), deployed 2026-07-27. Re-verify at T-15 in case a later revision rolled it back.
Merge freeze declared for the window; verify the served revision at T-15.
Say “offline POC — no ERP writes” once, at the top. Never per order.

Beat 1 — The pain mirror (3 min)

Screen: /inbox, Aurora — Order Nucleus, ungrouped, newest first.

“Today a PO for Streetsboro goes to a person in Streetsboro. A PO for Lunenburg goes to a different person, in a different inbox, typing into a different ERP. Eleven sites, eleven inboxes, nine or ten ERPs. Your customers who buy from all eleven have to know all eleven addresses.

This is one inbox. Everything Aurora received, wherever it was going.”

Scroll the queue. Let them see volume and the spread of senders and sites.

“Nothing here was typed by a person.”

Why it lands: it’s his Amazon analogy played back as a screen.

Beat 2 — It reads whatever they send (5 min)

The point: intake is not a format negotiation. Click one of each, in this order.

#	Click	Say
1	a PDF PO	“Structured PDF. Standard.”
2	an Excel order sheet	“Someone’s spreadsheet. Same queue, parsed, same line items.”
3	a scanned image PO	“This one was scanned. Still read.”
4	an email order	“And this one is just an email — no attachment at all.”

On the email, hit Show email ⇄ Show document to flip between the message and its attachment.

“Your customers don’t change how they buy because you bought software. This reads what they already send.”

Then the thread. Find a row badged +3 messages and open the Thread tab.

“This one is a conversation. A quote request, our reply, and then — three messages in — the actual PO. That’s the one your CSR has to notice.”

Point at the pills: RFQ → Skipped → Order.

“It read all three and decided which one was the order. The other two aren’t noise it ignored — they’re triaged, on the record, and it will tell you why.”

Why it lands: “the PO is buried in a reply” is a real, named Aurora pain — one of their own sample POs is a 7-page email thread with the PO partway in.

Beat 3 — The nucleus (8 min) ← THE BEAT

Open an order and put the Routing card on screen.

Routed: Ohio — Streetsboro → GP-1
Signals: ship-to "Streetsboro, OH" + vendor entity "Aurora Plastics" + item family GTPE
Confidence: High

Read the signals line out loud, slowly.

“It didn’t guess. Ship-to says Streetsboro. The vendor entity on the paperwork is Aurora Plastics, not S&E. The item family is GTPE. Three signals, one site, high confidence. That’s the nucleus deciding where this goes.”

Then the ambiguous one:

Ambiguous — needs routing review
ship-to "Carrollton, GA" → Pasadena, TX (GP-3), but vendor entity
"S&E Specialty Polymers" → Lunenburg MA (GP-4)

“And here it stopped. Ship-to points at Pasadena, the vendor entity points at Lunenburg. Two signals, two different sites. It will not guess — it hands you the reason and lets a human decide.

That’s the difference between software you can trust in 90 days and software your team turns off in three weeks.”

This is Angel’s moment — but the card is read-only. It states the conflict; it does not resolve it. Hand her the machine and resolve it where the controls actually are: the Split tab’s Route to picker (Beat 4) or a drag in /team (Beat 6). Say which one you’re doing — do not reach for a button on the card.

“It won’t guess, and it won’t bury the conflict. Angel decides — in the same two clicks she’d use on any other order.”

Honesty guardrail (say it before IT asks): the site/ERP proposal in this POC is a scripted map over your real sample POs, not a live model. The routing decision surface is real; the classifier is what we build against your data.

Beat 4 — Split one PO across sites (5 min)

Open a multi-line order → Split tab. Group lines, set each split’s Route to a different site.

“One PO. The wire compounds are made in Lunenburg, the profiles in Streetsboro. Today a CSR splits this by hand — retypes half of it into another site’s ERP and emails somebody to go do the other half.

Here it’s two destinations on one order. Each half goes where it’s made.”

“This is the 50-orders-a-day, two-hours-a-day number. Not entry. Movement.”

Why it lands: movement is the biggest time sink he named, and no competitor demo touches it.

Beat 5 — Exceptions are the product (5 min)

Three of their own documents. Frame them as wins, never as failures.

The verbal order (VERBAL-RL 415 PO.pdf) — no PO number, no item number. The line reads “a bag of Honeywell 416”, price Missing, No ERP match.

“This is a phone order somebody typed into an email. No PO number, no item number, no price — just ‘a bag of Honeywell 416’.

Watch what it did not do. It didn’t guess an item and it didn’t book a zero-dollar line. It pulled the words out, landed it in the right queue, and put one search box in front of your CSR.”

Type Honeywell in the ERP-catalog search and assign the match on stage.

“Two seconds, and it’s a real line. Compare that to finding this email in somebody’s personal inbox three days later.”

⚠️ Do not say it auto-matched. It doesn’t, and Angel will click it. The codeless-lines path that would bind this automatically is enabled for the org, but nothing has re-run the matcher over this document in the offline POC.
The $0.00 total (13830 JULY WHT PO.pdf, MI Profiles). Put the document and the footer on screen together: the PDF prints a $0.00 grand total; the footer reads $3,290,000.00.

“Look at their own PO — the grand total on the document is zero dollars. Now look at our total: three point two nine million.

We price from the line, not the document’s total field, so a broken total on a customer’s template can’t book you a zero-dollar order. That’s a three-million-dollar difference on one PO.”
The clean one, for contrast (POUS102896.pdf, TriCab). Auto-matched, 1 of 1, ready.

“And this is what the boring 80% looks like. Matched, priced, ready — your CSR touches it once to approve.

Note you can still Change match on any line. That override is the signal we learn from: the cross-reference the system builds so it gets this right without you next time.”

(Careful: 405BK and 406BK are near-identical siblings in their catalog. This order matches cleanly today — do NOT claim the system caught a digit error here. The genuine abstention beats are the verbal order and the ambiguous routing card.)

“Clean orders route quietly. You’ll only ever see the ones worth your time. That’s the 90-day arc — heavy review at first, then exception-only.”

Click a line item to show the highlight land on the exact row of the source document.

“Every number we pulled points back at where it came from. Your CSRs are going to pick this apart — Robert told me Angel would. Good. This is built to be checked.”

Beat 6 — Supervisor / network view + re-routing (7 min)

Screen: /team. Open on the TEAM LOAD rail, then switch Table ⇄ Kanban.

The left rail is the workload story with no narration needed — every plant with a live count (Streetsboro 8, Lunenburg 7, Pasadena 4, Welcome 4, Evansville 3+3, Marieville 3, Louisville 3). Read those off the rail, not off this page — the drag below moves two of them. They sum to 35, not the 42 the runbook quotes: the rail counts open work only, and 7 of the 42 are already submitted (35 awaiting_review + 7 submitted = 42). Verified against the database 2026-07-27 — they are not archived.

“This is your view, not the CSR’s. Every plant, what’s queued, who’s buried and who’s idle — one screen instead of eleven inboxes you can’t see into.”

Then re-route, live. Kanban → Lens: By assignee gives one column per plant. Drag a card from one plant to another.

“That order landed at Louisville. It belongs at Lunenburg. Watch —

That’s the move your CSRs make fifty times a day. Today it’s a retype into a second ERP and an email asking someone to go do it. Here it’s a drag.”

The By connection lens is the honest one to show if IT asks: it’s the real ERP dimension the product gains once multi-connection lands, versus the site-as-assignee model this POC runs on.

“Thirteen CSRs at two-plus hours a day of order movement is roughly five to six full-time people worth of time. That’s the number for your PE sponsor.”

Verified 2026-07-27: a site user reassigned an order from Louisville (IQMS-2) to Lunenburg (GP-4) and it persisted. The assignee list is org-wide — apps/webapp/src/pages/api/work-items/bulk-actions.ts validates against isUserInOrganization, not the connection — so any plant can hand work to any other plant.

Beat 7 — Hands-on (20 min) — Robert asked for this

Give Angel the keyboard. Let her try to break it. Do not narrate over her.

Have ready:

The reset command (runbook) if she wants a clean queue.
An honest answer for anything unbuilt: “not built — here’s what it takes.”

Beat 8 — The close (5 min)

“You said the nucleus is the thing. That’s what you just watched: one landing zone, a routing decision with its reasons shown, and a split when one PO belongs to two sites.”

Exit criteria — ask for all three:

Item master from one or two sites (the single highest-value unblock).
A pilot site — GP-first; IQMS is on the roadmap, say so plainly.
Security-review kickoff (on-prem, no portal, NDA already in place).

Do not say

❌ “AI figured out where it goes” → say “three signals agreed”
❌ “It’s already learning your routing” → route learning does not exist; cross-reference learning does. Don’t blur them.
❌ “Simulated” more than once → once, at the top, then never again.
❌ Anything implying a customer-facing portal — hard no on their security posture.
❌ Naming a delivery date for multi-connection routing. The 6+ month implementation expectation is already set; don’t renegotiate it on stage.

Verification status (updated 2026-07-27)

Every beat was walked against staging. What was actually confirmed on screen:

Beat	Status	Evidence / caveat
1 Pain mirror	✅	42 orders across 8 site queues, all previews render
2 Formats	✅	PDF / Excel / scanned image / email each render in the cockpit and review-v2; Show email ⇄ document toggle works
2 Thread	✅	`+3 messages` badge + Thread tab; RFQ → Skipped → Order pills; “This message” marker
3 Routing card	🟢 deployed	Merged in #2652 and present in the deployed staging build (`5dbfae9a9`, 13:54Z). Component + 32 signals tested (`AuroraRoutingCard.test.tsx`, 9 tests). Build-provenance check — eyeball it on screen at T-15
4 Split to site	🟢 deployed	Same build: `quote_splits.target_connection_id` + the Route-to picker. Round-tripped on a local build earlier; not re-eyeballed post-deploy
5 Verbal order	✅	Renders as an honest abstention — script corrected, it does not auto-match
5 ERP item search	✅	Fixed 2026-07-27: every order was missing `erp_company_id`, which ERPSearchModal hard-requires (no submit gate mentions it) — the search box was dead on a fully-validated order. Type `Honeywell` on the verbal order to prove it live.
5 $0.00 total	✅	Doc prints $0.00, footer reads $3,290,000.00
5 Clean order	✅	TriCab auto-matched 1/1 — script corrected, it is not a digit catch
5 Highlighting	✅	66/66 line items carry a highlight primitive; toast gone
6 Supervisor	✅	Fixed 2026-07-27: all 8 site users now carry the `manager` role, so `/team` opens for them. Cross-plant reassignment verified live — Louisville → Lunenburg persisted, then restored
7 Hands-on	n/a	—

The one thing to re-check at T-15: open any order and confirm the Routing card renders, then split one and set two destinations. Both shipped in #2652 and are in the deployed build — but they are the only two beats never eyeballed on deployed staging, so look before you present.

If something breaks

Breaks	Do this
A preview won’t load	Move on to the next order; come back. Never debug on stage.
Routing card missing	The flag or the branch isn’t live — skip to Beat 4, cover routing verbally with the requirements doc’s worked example.
Submit errors	You’re in approval-only mode by design — use Finished, and say “no ERP writes in the POC.”
Whole app is wrong	Screenshots in the runbook; keep talking. The story is the nucleus, not the pixels.