Foodservice isn't short on opportunity. It's short on capacity.
Tyson Foods' Foodservice sales organization wasn't losing deals because the market wasn't there. It was losing selling time to operating complexity. Product and account information lived across eight-plus disconnected internal systems. CRM updates happened in Friday-afternoon batches instead of in the field. A recent field-team consolidation meant fewer reps were covering the same account base, with no system telling anyone where to focus first.
A cross-functional leadership workshop named the real constraint precisely: sales capacity was being diluted by friction and fragmentation, not held back by a lack of demand. The mandate that came out of it reframed the whole project. The goal isn't to automate selling. It's to remove the internal complexity standing between reps and the selling they're already capable of doing.
Twelve interviews, two segments, one clear signal
Before any screen got designed, the project ran through a deliberate discovery sequence: a leadership workshop to name the real constraint, a cross-functional capability-definition workshop that turned dozens of raw requirements into a force-ranked build roadmap, and a lightweight prototype taken directly into the field.
I joined at the design-and-build phase, inheriting a strong research foundation: twelve field interviews split across two sales segments, plus a dedicated stakeholder session with the segment's VP sponsor and a follow-up discovery session with all twelve pilot reps focused specifically on what they'd want an AI assistant to answer, in their own words.
The information is definitely there. It's just scattered.
— Sales Manager, 5 years' tenureEvery one of the twelve reps described the same experience: the answer to a product or account question existed somewhere: a shared drive, a colleague's spreadsheet, a system nobody else on the team used. But finding it cost real selling time. The clearest articulation of the stakes came from reps who'd used a competitor's field tool at a previous company: several people independently compared it favorably to what they had now.
I was shocked that, at the size of company Tyson is, the technology kind of went backwards.
— Sales Manager, 5 years' tenureA second pattern was just as consistent: without exception, every rep described updating the CRM as a Monday-and-Friday batch task, not something they touched in the field, not from unwillingness, but because the mobile experience made real-time entry impractical. For one segment specifically, checking a customer's group-purchasing status before every call, a compliance requirement and not a nice-to-have, depended on a desktop-only tool nobody could use between stops.
The signal across both segments was strong and largely unconditional: eleven of the twelve reps said yes to the direction outright. The one segment with any hesitation tied every condition to a single, specific ask: that the tool write directly back to the CRM instead of becoming one more system to maintain.
Five tabs, one job: shorten the gap to selling
This is the build currently in the field with the pilot group, actively iterating, with me writing and shipping the code myself. Today surfaces the day's priorities and performance at a glance; Hunt turns the prioritized opportunity queue into a working list or board; Record captures field notes hands-free; Tasks pulls the day's admin and meetings into one place with auto-handled items called out explicitly.
Rep identity, account names, and deal-specific figures are redacted throughout. The underlying data is real, active field data, not placeholder content.
The chat feature: redesigning for trust, not novelty
The first feature I took ownership of was the in-app assistant reps use to ask product, stocking, and account questions in natural language. It's the single highest-adoption-driving feature in the research, and also the highest-risk: one confidently wrong answer in week one of a pilot is enough to lose an experienced rep's trust permanently. Every design decision on it traced back to a specific research finding.
Reframed the headline
Replaced a generic "What do you want to know?" with language naming the exact moment reps said they needed it most, the minutes before walking into a call, without overclaiming what an early-pilot assistant can promise.
Traded prompts for orientation
Three tappable, consumer-flavored suggested prompts didn't reflect a single real question from the research. They became four non-tappable cards, each mapped to a genuine top-priority question type reps actually asked in discovery sessions.
Added voice input
Reps are driving between calls, not typing. A microphone existed elsewhere in the app but was missing from the chat input itself, a direct contradiction of the voice-first principle the research made non-negotiable.
Cut chat history for pilot
Simpler to build, easier to trust, and it keeps the capability reminder visible on every session open. The tradeoff was deliberate: prove the core lookup experience works before adding complexity on top of it.
Some decisions took more than one pass to get right. The headline alone went through rejected versions before landing. One risked sounding like overclaimed expertise; another was accurate but read as confrontational toward the systems reps were already frustrated with. Small wording choices mattered more than usual: the placeholder text under the input field was rewritten to name the most-requested question types directly, so reps understood the tool's scope before they typed anything.
Every decision on this project gets tested against the same three questions: does it redirect a rep's time toward selling, does it reduce friction, and would the broader orchestration model fail without it. A fourth, blunter test came straight from the field: could a rep use this without opening a laptop. If the answer was no, the design was wrong for the context.
What's still unsolved
Pilot software should be honest about what it doesn't do yet. Four gaps are next in line, all identified directly from research, not guessed at afterward:
Response format
Current answers read like documentation: bulleted, formal. A rep relaying an answer out loud mid-conversation needs something closer to how a person actually talks.
Clarifying questions
The assistant sometimes asks two questions at once when a request is ambiguous. Field reps need one question, answerable in a single tap.
Graceful failure
There's no designed state yet for "I don't have that." This is the most trust-critical gap. The first inaccurate guess is what decides whether an experienced rep keeps using the tool.
Artifact access
Spec sheets and product images should be available on request after an answer, not bundled into every response by default. That affordance isn't designed yet.
Where it stands
Field reps across two sales segments who backed the orchestrated-selling direction during prototype validation, before final designs existed.
Reps in the current live pilot, spanning both segments, testing the shipped build in the field right now.
Reps targeted for Phase 1 scale across the broader Foodservice sales organization, once pilot results validate the approach.
The app is live in beta on the App Store, in active field use. Because the pilot is still running, I'm treating adoption signal from newer reps and from tenured reps as different kinds of evidence. A new rep adopting a tool they were simply handed says less than a five-year rep choosing to abandon a workflow they already trusted.
What I'm watching for
Research made one thing clear before I designed a single screen: accuracy is a precondition for adoption here, not a feature to iterate toward. Experienced reps said, unprompted, that they'd stress-test the assistant against their own knowledge in the first week, and that a handful of wrong answers early would be enough to write it off entirely. That reshapes how I'm prioritizing right now: it's better to answer a small number of questions reliably than a large number unevenly, even if the pilot build looks narrower than it could. I'd rather earn trust slowly than lose it fast.