Design: Phone-Order Capture (Shadow Mode) — VoIP as the Next Order Source

Generated by /office-hours on 2026-07-12 Branch: claude/voip-order-automation-d257b6 Repo: erp-unlocked (Ordermatic) Status: APPROVED Mode: Startup

Problem Statement

Ordermatic today ingests orders from one channel: email (Gmail pull → PDF/body AI extraction → validation/matching against ERP catalog → draft order in the review inbox → CSR approves → ERP submit). A meaningful segment of the market takes most of its orders by phone, and this surfaces as a recurring fit objection in cold outreach (“most of our orders come in by phone”). The question this doc answers: what is the cheapest credible way to find out whether phone-order capture is a product, and what should the first version be if it is?

The pipeline downstream of extraction (matching, pricing, validation, flag-gated ERP submit) is channel-agnostic and already exists. The new surface is: obtaining call audio, transcription, and extraction from conversational (rather than document) input.

Demand Evidence

Quantified in-session from HubSpot (3,795 logged cold calls, Aircall summaries). Method, for reproducibility: HubSpot CRM search on the calls object run 2026-07-12 over all logged calls to date (matched calls span 2026-02-02 → 2026-07-10); filter hs_call_body CONTAINS_TOKEN "phone" AND ("order" OR "orders"); bodies are Aircall auto-summaries (Call Summary / Key Topics / Tags). Token matches were then hand-classified: “genuine channel statement” = a prospect describing how their orders arrive, excluding IVR/phone-menu descriptions and incidental “phone number” mentions. Findings:

• 33 calls mention phone+order tokens; 9 are genuine channel statements from prospects.
• 5 of the 9 explicitly said manual order entry is NOT painful: Anthony Smith (President, Texas Bearing): “majority of orders come in by phone… don’t have an issue with volume.” Tim Jarosz (IT Mgr, Standard Air & Lite): “most orders via web or phone… not enough volume to justify ROI.” Seth (Holder Electric Supply): “majority of orders come in by phone… not really a pain point.” Bill Hemmelgarn: majority via device auto-alerts or phone, “not applicable.” Dustin (Rick Guill’s company): rekeys phone/text/email orders but “don’t necessarily have an issue.”
• Mixed-channel, verdict TBD: Tricia Bakke (LB White): “orders arrive by email and phone, manually entered by customer service” — ERP owner (Dan) was on vacation; follow-up open.
• Most open prospect: Charles Stanford (IT Mgr, Epicor Eclipse shop): “most customers call in orders or text them… no formal process.”
• Text/SMS orders mentioned unprompted twice (Stanford; Dustin at Rick Guill’s company: “mix of phone calls, texts, emails… manually rekey”).
• Remaining 2 of the 9: Jamie Neuburger (e-commerce GM: CSRs process email+phone orders, but already signed with Esker) and Brian Putnam (counter-example: “don’t really get orders over the phone”).
• Installed base: Genfit (existing paying customer, food distribution) takes phone orders. They have not asked for this feature.

Honest read: this is a fit objection plus inference, not customer pull. Phone-heaviness kills deals because the email-pain narrative doesn’t land there — not because those prospects asked for phone capture. Demand is research-grade, not build-grade. One observation session away from knowing.

Secondary (defensive) evidence: document-order-entry competitors (Canals, WizCommerce “Ella”) are adding voice; “do you handle phone orders?” is trending toward table stakes in competitive deals.

Status Quo

Unknown — and it is the load-bearing unknown. When a CSR at a phone-heavy shop takes an order call, they either (a) key it into the ERP live during the call (call IS the entry; no artifact; an after-call draft saves ~nothing), or (b) capture-then-key (paper/notepad/voicemail, entered later; an artifact gap structurally identical to the email wedge). The founder’s answer in-session: “honestly don’t know.” Five “no pain” responses in the CRM data are consistent with live-keying being common. Observation at Genfit resolves this before any build decision.

Target User & Narrowest Wedge

• Observation target #1: Genfit CSRs (existing customer, known phone-order volume, warm access, recordings likely obtainable this week).
• Design-partner candidate outside the base: Charles Stanford (Eclipse shop; call+text mix; “no formal process”).
• Control group: the “no pain” phone shops (Texas Bearing, Holder Electric, Standard Air & Lite) — revisit not to sell but to ask “walk me through what your CSR does during an order call.” LB White is a separate follow-up (mixed-channel, verdict TBD, Dan back from vacation).
• Narrowest wedge: a batch of already-recorded order calls, transcribed and pushed through the existing pipeline, producing draft orders in the existing inbox. No telephony integration. If the drafts are accurate and a CSR (or Stanford) reacts with “I want this running on our line,” the wedge is validated.

Constraints

• Small team; email product, POCs (Core & Main), and CK enablement are concurrent priorities — this must not consume a quarter on spec.
• ERP writes remain feature-flag gated (existing platform rule).
• Legal/privacy gate (prerequisite): documented legal/privacy approval is required before requesting, exporting, retaining, or processing any customer call audio — not just before ingesting it. The approval must cover: notice/consent basis (incl. two-party consent states), retention limit for the sample (default: delete audio + transcripts within 30 days of the shadow-mode eval unless re-approved), access controls (founder + one engineer only; no copies outside GCS), deletion on request, and sensitive-data handling (treat audio as sensitive per the WhereFour cardholder-data precedent — callers may read card numbers aloud; redact before any LLM processing).
• Premise P5 (modern VoIP APIs only, ancient PBXs out of scope) applies to any post-shadow-mode capture build (Approach B). Shadow mode itself uses no VoIP APIs — recordings arrive by manual export/upload.

Premises (agreed in-session)

1. Evidence = fit-objection + inference, not customer pull. This is research, not a committed build.
2. Build decision is gated on observation: watch Genfit CSRs take phone orders before designing architecture. No architecture until the live-key vs capture-then-key question is answered with eyes.
3. If built, it is a listener, not an agent. Passive capture behind the human CSR feeding the existing draft-review inbox — explicitly NOT an AI voice agent that answers calls. In relationship-driven distribution the call is the moat; the end customer’s experience must not change.
4. (Revised after cross-model challenge) First deployment goes to the first account meeting three criteria: observable phone-order pain, recording access, shadow-mode willingness. Genfit is candidate #1 because it best satisfies the criteria — not because “installed base first” is a law. Falsification test: if Genfit is polite-but-non-urgent while a phone-heavy prospect (Stanford) would pay for accurate drafts on a batch of his recordings, believe the money.
5. Capture (Approach B and later) rides VoIP-provider recording APIs (Aircall/RingCentral-class webhooks; ~15-min post-call media windows; speaker-labeled transcripts available). No SIP-level or hardware capture. Not a shadow-mode constraint — v1 ingests manually exported recordings.

Eureka (logged): the voice-AI herd builds agents that ANSWER calls (deflection framing). In relationship-driven distribution the unclaimed half is passive listening behind the human — structurally identical to Ordermatic’s email wedge. The one fact that can kill it is live-keying.

Cross-Model Perspective

Codex cold read (independent, structured summary only, no conversation access):

1. Steelman: “An ambient order-capture layer for the phone channel, not voice AI. The CSR keeps the relationship call, while your system converts messy spoken orders into a structured, evidence-backed draft in the same review inbox and ERP-matching flow customers already use for email.”
2. Most revealing evidence: “most customers call in orders or text them, no formal process” — “the product is not really ‘VoIP integration’; it is ‘turn informal conversations into an order artifact.’ If you only think in telephony terms, you risk building the plumbing instead of the abstraction that matters: channel-agnostic capture for phone transcripts, voicemails, and SMS threads.”
3. Challenged premise: P4 (installed-base-first). Deploy first wherever pain + recording access + shadow-mode willingness intersect — possibly a paying prospect, not a polite existing customer. Accepted — P4 revised to the criterion (above).
4. 48-hour prototype: shadow mode, not production telephony. One input path (uploaded recordings / transcript JSON from one provider), commodity transcription, existing extraction/matching adapted to transcript turns, minimal inbox addition (Phone source badge, transcript/audio drawer, per-line-item evidence timestamps (later deferred to Approach B — see chosen approach), confidence, missing-field prompts). Skip: live streaming, CSR desktop assist, provider OAuth/webhooks, multi-provider abstraction, ERP auto-submit, any agent that answers calls.

Synthesis: both models converged on shadow-mode-first and on “informal channel → order artifact” as the real abstraction (which also explains the unprompted SMS mentions). Codex’s stack specifics (FastAPI/R2) don’t match the repo (Hono/TS/GCS) — cosmetic.

Approaches Considered

Approach A: Shadow-Mode Transcript Pipeline (minimal viable) — CHOSEN

No telephony integration. Obtain a batch of recorded order calls (Genfit export or provider download), transcribe with commodity STT (diarized), feed transcripts into the existing extraction→matching→validation pipeline, render drafts in the existing inbox with a Phone source badge and a transcript drawer with highlighted evidence spans (per-line-item audio timestamps are deferred to Approach B — span highlighting validates the same hypothesis without word-level alignment work). Single manual ingest path (upload endpoint or ops script). Effort S–M (Claude Code-assisted: ~2-3 days for plumbing; conversational-extraction quality work is the variable — v1 explicitly ships with NO customer-history prior and measures how far vanilla extraction gets before deciding whether a history prior is needed). Risk low. Reuses ~90% of the existing product.

Approach B: Channel-Agnostic Conversation-Source Platform (ideal end-state)

Proper source = conversation abstraction: VoIP connectors (Aircall/RingCentral OAuth + recording webhooks), diarized STT, voicemail + SMS ingestion, per-line-item evidence timestamps, per-connection channel config. Effort L–XL. Risk med-high: builds integration sprawl on unproven demand; recording-consent compliance work; violates premise P2 if started before observation. This is the destination if A validates — not the starting point.

Approach C: Informal-Order Drop Box (creative/lateral)

A source that accepts any informal order artifact — voicemail file, SMS screenshot, photo of a handwritten note, call recording — and drafts from it. Matches the “no formal process” evidence; zero integration dependencies. Con: upload friction (CSR must do extra work — the opposite of ambient). Fallback wedge if observation reveals capture-then-key via ad-hoc artifacts.

Recommended Approach

A — Shadow-Mode Transcript Pipeline, strictly sequenced AFTER the observation assignment. Rationale: cheapest experiment that converts “thinking about VoIP” into evidence; produces a demo for both Genfit (expansion) and Stanford (paid-pilot ask / P4 falsification test); defers every architecture decision in B until observation data exists. If shadow-mode drafts are accurate and wanted, B’s connector work proceeds with proof; if not, the total cost was days.

Open Questions

1. Live-key vs capture-then-key at Genfit — the gating fact. (Assignment.)
2. What phone system does Genfit run, and does it retain recordings we can export? (Determines whether shadow mode needs audio upload or can start from provider transcripts.)
3. Recording consent posture — which states are Genfit’s callers in; what does their current recording disclosure cover?
4. Extraction quality on conversational orders: colloquial product names (“the usual”, “same as last week”, quantities in shorthand) may lean harder on customer order history than email extraction does. Does the current matching stack need a customer-history prior?
5. Is SMS actually the faster wedge? (Two unprompted mentions; trivial capture; artifact-native. Revisit after observation.)
6. Does “phone orders supported” measurably move cold-call conversion? (Sales can A/B the talk track before any build.)

Success Criteria

• Research phase (2 weeks): observation completed at Genfit; live-key vs capture-then-key answered with direct evidence; 5–10 real order-call recordings obtained (if obtainable — the no-recordings contingency in Dependencies is a legitimate outcome, not a failed research phase).
• Shadow mode (if built, timeboxed to ~2 weeks of build+eval): ≥80% of line items extracted and matched correctly, measured as: founder (or CSR) hand-labels ground truth for every line item across the full 5–10 call batch (expect ~30–80 line items total as the denominator); grading is per-line-item across the batch, not per-call. Rubric (fixed before grading starts): a line item is correct only if product identity (matched catalog SKU), quantity, and unit of measure are all right; customer intent (order vs inquiry vs change) is graded per-call; abstentions count as incorrect unless the audio is genuinely ambiguous to the human grader too (mark “ambiguous”, excluded from denominator); partial matches are incorrect. Ground truth: one grader (founder or CSR), with a second grader adjudicating any line item the first marks ambiguous. A Genfit CSR says they’d use the draft over their current after-call workflow (only meaningful if capture-then-key); Stanford (or equivalent prospect) agrees to a paid pilot after seeing drafts of his own calls — the unfakeable signal. Stanford-path caveat: as a prospect he has no ERP connection or catalog in the system, so the 80% match criterion is Genfit-only; his shadow test is scoped to extraction quality (line items, quantities, customer intent pulled from audio), and a paid pilot for him requires a catalog export / mini-onboarding first.
• Shadow-mode decision rule: <80% at timebox end → park pending the customer-history prior (Open Q4) rather than extending the timebox.
• Kill criteria: park the channel only if BOTH legs fail — (a) Genfit observation shows live-keying with no after-call work and no voicemail/after-hours volume, AND (b) the prospect-side falsification test (Stanford walk-through) also shows no capture-then-key artifact. A Genfit-only “no” does not kill it — per revised P4, believe the money side before parking. If parked: revisit SMS/drop-box instead.

Dependencies

• Genfit relationship: access request via existing champion (founder-led).
• Contingency if Genfit recordings are unobtainable (no recording system, retention gap, or legal block): run the shadow test on Stanford’s recordings as a design-partner ask; if neither yields audio, do the observation anyway (it needs eyes, not recordings) and park the shadow build pending the SMS/drop-box wedge.
• Legal/privacy approval per the Constraints gate — a blocking prerequisite for assignment step (b) (requesting recordings) and for every downstream export/retention/processing step. Observation itself (watching calls) needs only Genfit’s ordinary visitor consent.
• Existing extraction/matching pipeline (packages/ai, webapp inbox) — no changes needed until shadow-mode build starts.
• STT vendor selection (Deepgram / OpenAI / Google — commodity; benchmark empirically per house rule, on real Genfit audio not samples).

The Assignment

Within two weeks: watch Genfit take phone orders. Screen-share or site visit; observe 2–3 live order calls end to end. Answer one question with your own eyes: does the CSR key the order into the ERP during the call, or capture it and key it later? While there: (a) ask what phone system they run and whether it records; (b) request 5–10 recent order-call recordings for the shadow-mode test — only after the legal/privacy gate in Constraints clears; (c) ask about voicemail and after-hours order volume (a kill-criterion input). Secondary: call Charles Stanford back — not to pitch, but to ask “walk me through what happens at your counter when an order call comes in.” Two conversations, zero code.