KwikTrip onsite — strategic prep

Working brief for the Aug 5-6 onsite. Goal per the Notion ticket: walk in framing the AI/data platform decision, not showing up as the person who implements a pre-decided Copilot rollout.

Logistics recap

• Onsite locked: Wed-Thu Aug 5-6, La Crosse WI (KwikTrip HQ, 1626 Oak St). [[2026-07-21-kwik-trip-aug5-6-travel-update]]
• Travel: fly MSN with the phData team (Taylon from SLC, Paulo from São Paulo) to land together via a shared ORD->MSN hop; drive ~2h05m to La Crosse. Out Tue Aug 4, back Fri Aug 7. Hotel: Hampton Inn & Suites La Crosse Downtown.
• Three phData travelers confirmed converging: Ben, Taylon, Paulo. No confirmation yet in the vault of who from KwikTrip will be in the room.
• This onsite is sequenced before the Andrew/Tiger-team conversation (~2026-08-14) — per the Notion ticket, a strong platform-framing outcome here strengthens that later conversation, not the reverse.

Stakeholder map

From [[2026-07-17-kwik-trip-engagement-notes-stakeholders-and-priorities]] (founder's handwritten notes, digitized):

New name surfaced in the Notion ticket itself (2026-07-31), not yet cross-referenced against the 7/17 notes: "Lalan" — described as a new platform lead, whose arrival is one of the three conditions making the room winnable (see below). The ticket does not reconcile Lalan against "Allay" — unclear whether this is a new/different person, a title change, or the same person under a spelling correction. Confirm Lalan vs. Allay as separate or same person before or at the top of the onsite — this materially affects who you're framing the platform decision to.

The platform-decision frame

What's actually at stake is not "should KwikTrip deploy Copilot" — Copilot Studio is already deployed and Sprocket (the store-engineering support agent) is already live in Teams. The decision on the table is narrower and more consequential: which underlying platform does the document-processing and retrieval layer run on, and does that choice get made deliberately now or by default because Copilot Studio is where the project started.

Per [[2026-07-31-sprocket-document-pipeline-tool-selection]] (built today, the most current and specific source in the vault):

• Sprocket is stuck at ~80% accuracy. The bottleneck is retrieval from equipment manuals, specifically diagrams — a diagram is pixels, and text-only chunking gives the retriever nothing to match a query against.
• Three conditions have converged to make this the moment the architecture gets re-decided (per the Notion ticket): (1) the existing Copilot-built agent is having trouble scaling past that accuracy ceiling, (2) a new platform lead ("Lalan") is arriving — new leads reopen settled decisions, (3) leadership is convening specifically to replace an organic "thousand flowers bloom" grassroots approach with a top-down one.
• The real tool question is UiPath's IXP vs. Databricks' ai_parse_document — not "Copilot vs. something else." IXP is built for structured field extraction from business documents (invoices, forms); ai_parse_document is explicitly built to capture tables, figures and diagrams with AI-generated descriptions and spatial metadata, at 3-5x lower cost at scale per Databricks' own claims. That's the exact failure mode Sprocket has. UiPath's earlier "third platform, weaker integration" framing has been withdrawn as an objection — its bi-directional Copilot Studio integration is first-class (Maestro, Enhanced Autopilot, MCP via Azure/AI Foundry) — so the case for Databricks has to rest on the parsing/retrieval fit, not on integration friction.
• The front end (Copilot Studio in Teams) does not have to move. Databricks ships managed MCP servers that plug into Copilot Studio as a Tool with no additional licensing beyond standard Copilot Studio — versus the same integration built as a Power Apps custom connector, which requires Premium licensing for every end user. The agent stays in Teams; retrieval runs in Databricks; no custom glue code. This is the architecture move that lets the founder recommend swapping the engine without asking KwikTrip to rip out what already works for end users.
• Separately, and adjacent: the "deskless employees" problem (no email, no MSFT identity — a distinct thread from Sprocket, whose users turned out to be Teams-based remote workers, not deskless) has its own platform-cost math worth having in the room: a full per-seat M365 Copilot rollout to KwikTrip's ~24k desk-less workforce would run roughly $8-9M/yr in licensing before anyone types a prompt ([[2026-07-13-kwik-trip-deskless-agent-distribution]]). That number is not about Sprocket, but it's the sharpest available proof point that per-seat vendor licensing doesn't scale to KwikTrip's workforce shape, and it's exactly the kind of number that reframes "just buy more Copilot" as a platform question rather than a shopping decision — directly on-theme with leadership's move from grassroots to top-down.
• KwikTrip's own hiring signal backs the "run lean, buy at the edge" read: 1,790 open postings scanned, zero titled data engineer/data scientist/BI/analytics, and the ~12-person Data Services team isn't visibly scaling via external hiring while the company adds 30+ stores/year ([[2026-07-11-kwik-trip-jobs-tech-signal-read]]). A small internal platform team is a structural reason architecture decisions get made by whoever shows up with a credible recommendation, not adjudicated by a large internal engineering org — which is exactly the room this onsite is.

Positioning talking points (lead the platform conversation, don't execute one)

1. Open with the accuracy ceiling, not the vendor comparison. "Sprocket is at ~80% and the blocker is retrieval on diagrams — that's a parsing/retrieval problem, and it's worth being precise about which layer is actually broken before picking a tool." This positions the founder as diagnosing, not pitching.

2. Separate the layers explicitly: parse/extract vs. retrieve/index vs. front end. Per the tool-selection doc's layer-mapping table, comparing IXP to Vector Search directly (or "UiPath vs. Copilot" as a single axis) produces a bad evaluation. Naming this distinction out loud is itself a senior move — it reframes a muddled bake-off into a structured decision.

3. Propose the 20-page pilot, not a platform verdict. "Whether ai_parse_document actually handles your exploded-parts diagrams is a pilot question, not a spec question — run it against ~20 currently-failing pages, one day of work, and it settles this with evidence instead of vendor claims." This makes the founder the person who de-risks the decision, not the person with an opinion — directly serves the ticket's framing goal.

4. Ask about Lalan/the new platform lead's mandate before assuming the answer. Whoever is arriving to move KwikTrip from grassroots to top-down almost certainly wants a defensible architecture story, not a vendor recommendation handed to them pre-baked. Ask what "top-down" is meant to solve before proposing what it should look like.

5. Do not disparage the existing Copilot buildout. The scaling problem is the opening, not a told-you-so — whoever built and sold the current agent may be in the room or adjacent to it. Frame as "this worked to get to a live agent; the next problem is a different kind of problem" rather than implying the original choice was wrong.

6. Surface the licensing-architecture point (MCP tool vs. custom connector) as a cost-governance issue, not just an engineering detail. It's concrete, quantifiable per-head, and it's the kind of detail that signals platform-level thinking rather than implementation-level thinking — the exact distinction the ticket asks the founder to establish.

Open risks / unknowns

• "Allay" (7/17 notes) vs. "Lalan" (Notion ticket, 7/31) is unreconciled. Could be the same name transcribed two ways, two different people, or a title/role change. Confirm before leaning on either name in the room.
• Whether Genie One (Databricks' front-end option) handles image input as first-class is unverified. Sprocket's workflow starts with a technician photographing a serial number — Copilot Studio in Teams handles that natively today. This is flagged in the source doc as "cheap to check directly" and likely a bigger determinant of the front-end question than any parsing benchmark. Not confirmed as of this brief.
• No vault record of who from KwikTrip will be in the onsite room beyond the stakeholder map above (which itself predates the "Lalan" name). Confirm attendee list before Aug 5 if possible.
• KwikTrip's UiPath licensing status (sunk/enterprise-wide vs. marginal) is unconfirmed — changes the marginal-cost argument in the platform recommendation, though not the underlying fit argument (diagrams are still Databricks' strength).
• Qmd search for anything dated after 2026-07-21 turned up nothing newer and more specific than the 2026-07-31 tool-selection note already covered here — that note (built today) is the most current material in the vault and is the primary source for this brief's platform frame.
• The $8-9M/yr deskless-Copilot cost math is a strong prop but belongs to a separate thread (the "deskless employees, no MSFT ID" problem) from Sprocket's own document-pipeline decision. Use it as supporting ammunition for the broader platform conversation, not as if it's a Sprocket-specific number — conflating the two would be an easy factual misstep in the room.

Sources

• [[2026-07-31-sprocket-document-pipeline-tool-selection]] — primary source for the platform-decision frame (UiPath vs. Databricks, diagrams-break-RAG, licensing/MCP integration, front-end options)
• [[2026-07-21-kwik-trip-aug5-6-travel-update]] — onsite dates, travel logistics
• [[2026-07-17-kwik-trip-engagement-notes-stakeholders-and-priorities]] — stakeholder map, "Allay" name flag, Sprocket priority + deskless-employees as a separate thread
• [[2026-07-13-kwik-trip-meeting-prep]] — company snapshot, original discovery questions
• [[2026-07-13-kwik-trip-walk-in-card]] — pre-discovery candidate portfolio, discovery posture
• [[2026-07-11-kwik-trip-jobs-tech-signal-read]] — hiring corpus (1,790 postings), lean-internal-team read
• [[2026-07-13-kwik-trip-deskless-agent-distribution]] — M365 Copilot cost-at-scale math (~$8-9M/yr), separate deskless-worker thread