Sales Training · Roleplay Sim · AI Value Discovery

Maya Reeves Call Companion

A live-call navigator for the AI Value Discovery roleplay. Every scored behavior on the rubric is covered, Maya's typical phrasings are flagged so you recognize the moments that matter, and the trickiest points are called out up front.

WIN CONDITION: Book the roadmap session with the right people in the room PASSING BAR: 70% · 27 scored items

The 4 Easiest Points to Lose

read these before you hit record

1The disguised chatbot objection WORTH 2 POINTS

This single moment covers two separate scored items (the chat-vs-agent explanation AND the chatbot objection). The trap: Maya raises the concern while agreeing with you, so it doesn't sound like an objection at all. She won't say "chatbots failed us." She says:

"So it's more like a helper, not a replacement or some black box... We've seen some tools that just throw answers at you without context, and that doesn't work for us."

The moment you hear "tools that just throw answers" or "black box," STOP and make the comparison explicit. Do not move on just because she sounds satisfied.

Totally get that, and you're right to be wary. Those are basically chat or lookup tools: you ask, they answer, and that's where it ends. What we're talking about is genuinely different. These assistants sit inside your workflow. They monitor orders and inventory, take the routine steps you're comfortable automating, like drafting an exception resolution or updating an order within rules you set, and they only hand off to a person when something needs judgment. So it's not retrieving information. It's moving the work forward while your team stays in control.

The scoring wants an EXPLICIT contrast: name what chat/retrieval tools do, then name what agents do differently (action, workflow, escalation, oversight). Implying it is not enough.

2Drop one proof point after she names her pain

Don't force customer stories early, but once Maya's context is clear, ONE grounded example is expected. The trigger: right after she confirms exception chasing is the biggest drain.

"Definitely the constant manual chasing of exceptions... It eats up a lot of time and energy."
For context, we helped another manufacturer cut down exactly that kind of manual exception chasing. We set up an assistant to monitor order issues overnight and route only the tricky ones to planners in the morning. We'd still need to validate your data and processes before promising anything similar, but it shows the kind of outcome we'd aim for with you.

Formula: one example + tied to HER stated pain + explicit "we'd still need to validate" hedge. That hedge is what keeps it from counting as an invented claim.

3Beat the agenda deflection at the close

Maya will not hand you a firm booking. She deflects with homework, and it's tempting to accept it and end the call:

"If you send over the agenda, I'll take a look and get back to you. No promises yet."

Ending there reads as a vague close and drops the point. Convert it into a two-way action with owners and dates. Keep the tone easy:

Perfect, that works. Here's what I'll do: I'll send you the draft agenda by Friday, including what little prep is needed so nobody's stretched. Once you've had a chance to review it with Liam, could you shoot me two or three times that work the following week? Then I'll send the calendar invite to lock it in. Sound fair?

The pattern: my action + my deadline + her small action + her deadline + the invite. Mutual ownership, still consultative. That's exactly what the rubric scores.

4Hit watch-out #1 the FIRST time it appears

The "tools that throw answers" line typically comes mid-call, right after you explain the helper concept. That's the earliest and best window, and she won't hand you a second chance; the topic doesn't come back. Insurance policy: front-load the chat-vs-agent contrast into your core explanation (section 3) so the point is banked even if her phrasing slips past you in the moment.

00

30-Second Snapshot

read before recording
Who
Maya Reeves

Head of Mfg Ops, Asteron Components. Former contact from a previous company, ~9 months in role. Warm but guarded; agrees quickly then adds conditions.

Her #1 pain

Manual exception chasing on the floor. "Eats up time and energy that could go into productive work." Build your anchor use case here.

Her #2 pain

Inventory visibility. Shortages and overstock caught too late, disrupting production flow. Good secondary use case.

Systems (her words)

"A bit of a patchwork." Homegrown ERP runs core, newer tools and some cloud layered on. Weak real-time visibility. She wants data validated before AI.

Key person

Liam, IT manager. Hands-on, pragmatic. No formal AI owner named yet. She wants Liam in from the start and checked with before anything is locked.

Her conditions for the follow-up

Focused and practical, no fluff or sales pitch, respects current workload, clear goals and scope, agenda + prep sent in advance.

01

Opening & Agenda

Metric 1.1 – 1.2

Set the agenda, lower the pressure

"I'm being asked what our AI strategy is, and honestly I don't have a good answer yet... Can you help me understand where it could realistically help us and what a sensible next step would be?"
Maya, it's great to reconnect. Thanks for carving out time. Here's what I had in mind: I'd love to hear what's driving the AI strategy question on your side, then I can share how we're seeing manufacturers like Asteron approach AI in plain terms, and if it feels useful, we can sketch a realistic starting point. No pitch today, just a working conversation. Does that work for you?

Rubric rewards natural agenda-setting that lowers pressure and positions this as a practical AI strategy discussion, not a hard sell.

Confirm what SHE wants before going deeper

Before I dive into questions, what would make this a genuinely good use of your time? What do you want to walk away with?
"A clearer sense of what AI can actually do for our manufacturing operations right now, not just in theory, and a straightforward idea of a first step without causing disruption or needing a big overhaul upfront."

This is its own scored item, separate from the agenda. And she hands you the whole call in that answer: practical, first step, no disruption, no overhaul. Echo those exact words in your close.

02

Discovery Questions

Metric 1.3 – 1.6

The trigger question (ask this first)

What prompted leadership to raise the AI strategy question now? And what have you observed so far?
"Partly the usual pressure to keep up with tech, partly frustration with how much manual exception chasing is still happening on the floor... I'm also hearing what other manufacturers are trying, but it's a bit vague."

Strong discovery starts with her trigger and perspective, never with assumed pains.

Operational priorities

When you look across the operation, where does your team lose the most time or take the most risk today? Scheduling, exceptions, quality, procurement, inventory, on-time-in-full?
"Definitely the constant manual chasing of exceptions and trying to figure out where things are slowing down."

The moment she says this → drop the proof point (Watch-out #2). Later she volunteers inventory visibility as a secondary pain; acknowledge it but keep exception chasing as the anchor use case.

Current state: ask, never assume

I don't want to make assumptions about your systems. What do you know for certain about the current landscape, and what would honestly need validating before anyone plans AI on top of it?
"We've got a mix... homegrown ERP still runs core stuff, newer tools layered on. A bit of a patchwork... We need to validate what data we can trust and where the gaps are. That's a big unknown for me."

Gold: she names data validation as her big unknown. That becomes the stated purpose of your discovery session in the close.

Stakeholder mapping

Beyond you, who would need to be part of this? Whoever leads IT, anyone tagged as the AI owner, ops excellence, ERP program lead, finance. Who validates the current state, and who governs adoption?
"Mainly me on the operations side, but IT has to be involved, especially around data and governance. Then leadership who want clear direction before committing budget."

Later she names Liam, the IT manager, as the likely AI owner. Use his name in the close; it makes the ask concrete.

03

Plain-Language AI Explanation

Metric 2

The core explanation, with the chatbot contrast BUILT IN

Instead of one big AI project, think of it as adding capable digital assistants into the workflows your team already runs. And I want to be clear about what these are NOT: they're not the chat tools you've probably seen that just throw answers at you and stop there. These actually do work. They watch orders, inventory, exceptions, take the routine steps within limits your team defines, like drafting an exception resolution or updating an order within your rules, and hand anything needing judgment to a person. Your people stay in control; the software just stops them drowning in the repetitive stuff.

Front-loading the contrast banks the chat-vs-agent scored item early. When Maya raises her "tools that throw answers" line later, reinforce with the Watch-out #1 script; that banks the objection-handling point too. Never lean on labels like the platform brand names as if the names explain anything; the rubric scores substance, not branding.

Start from current reality (the migration point)

And you don't have to finish a migration or be fully in the cloud before this planning starts. Roadmap and use-case prioritization can begin from exactly where your systems are today, patchwork and homegrown ERP included. The support is designed to add value across the whole journey, not just after everything is modernized.
"That's good to hear. I was worried this might be something we have to wait on until the ERP program settles down."

Key scored idea: planning starts before every system is perfect. This is also the heart of the platform story: value throughout the migration journey, not only after go-live.

The four practical ideas (translate, don't label)

  • Agents → "digital assistants that take action on routine work, like resolving order exceptions"
  • Role-based experiences → "your scheduler sees scheduling, your buyer sees procurement; each person gets what's relevant, not a generic dashboard"
  • Orchestration → "a shortage flagged in inventory automatically kicks off the right follow-up in purchasing"
  • Governed control → "IT defines the guardrails: what runs on its own, what needs sign-off, full audit trail"

The credibility rule

I'm deliberately not throwing ROI percentages or pricing at you today, because any number I gave you before we've validated Asteron's data and current state would be a guess. The honest specifics come out of the discovery workshop.

Never invent metrics, pricing, proof points, or capabilities. Saying this out loud actively earns trust with Maya, and it pairs perfectly with her own words about needing to validate data first.

04

Use Cases: Co-Create, Don't Pitch

Metric 3

Anchor use case: exception chasing (her #1)

You said exception chasing is the biggest drain. Picture an assistant that monitors order exceptions overnight, drafts the resolution for the routine ones, and routes only the tricky ones to your planners in the morning with the context already assembled. Instead of two hours of triage, it's a review-and-approve pass. Does that sound realistic for how your floor actually works?
"That sounds promising, but I'd want to know how much setup that requires and if it can fit with our current processes. We can't afford a big disruption."

Her pushback is about setup and disruption, not value. Answer with the start-small path below, never with a bigger pitch.

Secondary: inventory visibility (her #2)

And on the inventory side you mentioned: an assistant tracking shortages and overstock against demand, flagging them days earlier and proposing the fix within thresholds your buyer sets. But I'd keep that as candidate number two; exception chasing sounds like the bigger win.

Naming a second candidate and consciously deprioritizing it shows co-creation, not a product tour.

Proof point (Watch-out #2 lives here too)

For context, we helped another manufacturer cut down exactly this kind of manual exception chasing with an overnight assistant routing only the tricky cases to planners. We'd still need to validate your data and processes first, but it shows the kind of outcome we'd aim at.

One relevant, hedged example after her context is clear. Never lead with proof, never invent outcomes or numbers.

The safe start-small path

The way this works well is deliberately unglamorous: a short discovery phase to validate the data and current state, then ONE prioritized use case with governance agreed up front, and only then talk about scaling. No big-bang rollout, and no sitting on our hands waiting for the ERP program to settle either.
"That sounds more like what we need. A clear manageable step that doesn't disrupt the team or require a leap of faith."

Scored: staged adoption and pressure relief. Avoid big-bang language AND avoid passive "wait for go-live" language.

Ownership stays with Asteron

To be direct about roles: this is Asteron's roadmap, not ours. Your team, and honestly your IT team specifically, owns the strategy and the governance guardrails. We bring the platform, and separately services and expertise to accelerate it. You stay in the driver's seat on all of it.
"We're cautious about making sure IT owns the governance piece. We don't want a vendor-led roadmap that sidelines our internal teams."

She raises this in her recap correction near the end. If you've already said it proactively, just re-affirm: "Completely agree, and that's exactly why Liam should co-own the session."

Objection Quick-Fire

Metric 4 · tap the one she raises

Pattern for every one: Acknowledge → Clarify → Reframe → Check. Concerns she never raises auto-pass, so don't invite objections you don't need. She reliably brings up: the chatbot concern (disguised as agreement), ERP timing (softly), budget/pilot, setup/disruption, and IT ownership. The chatbot one is the trap.

THE TRAP: the disguised chatbot objection

"So it's more like a helper, not some black box making decisions on its own... We've seen some tools that just throw answers at you without context, and that doesn't work for us."

This sounds like agreement. It is the chatbot objection, and it covers two scored items at once. Stop and make the contrast explicit:

ACKNOWLEDGETotally get that, and you're right to be wary. Those tools earned the skepticism.
NAME WHAT THOSE WEREThose are basically chat or lookup tools. You ask, they answer, and that's where it ends. No context, no action.
NAME WHAT THIS ISThese assistants sit inside your workflow. They monitor orders and inventory, take the routine steps you're comfortable automating, and only hand off to a person when something needs judgment. Not answering questions, moving work forward, with your team in control.
CHECKDoes that distinction land? Because it's the whole difference between what frustrated you before and what we're describing.
NEVER: nod along and move on. Her satisfied tone is the trap. Make the chat-vs-agent contrast out loud, in full.

ERP timing: "Do we have to wait for the ERP program to settle?"

"I was worried this might be something we have to wait on until the ERP program settles down. We can't afford to put everything on hold."
ACKNOWLEDGEThat's the most common assumption I hear, and it's a fair one.
REFRAMEThe discovery work is low-disruption by design: a handful of working sessions, not an implementation. And doing the AI roadmap alongside the ERP thinking protects you, because you avoid ERP decisions that box out the use cases you'll want later.
CHECKDoes a low-disruption discovery phase, deliberately designed not to compete with the ERP program, address the concern?

Budget: "We can't throw budget at an open-ended pilot"

"I'd want to see how that works in practice before committing. We can't just throw budget at an open-ended pilot."
ACKNOWLEDGEThat fear is earned. Plenty of AI pilots wander for a year with no finish line.
REFRAMEThat's exactly why it's structured as a predictable discovery path: defined scope, defined timeline, success measures you agree to before anything starts, and a clean go/no-go decision point. You always know what you're spending, what you're measuring, and when you decide.
CHECKIf the success measures and decision points were agreed up front, would that make it fundable on your side?
NEVER: offer discounts or invent ROI figures. Predictability, governance, agreed success measures.

Setup / disruption: "How much setup does that require?"

"I'd want to know how much setup that requires and if it can actually fit with our current processes. We can't afford a big disruption just to try something new."
ACKNOWLEDGEIf the pitch were "transform everything at once," I'd tell you to run. That version does fail.
REFRAMEThe approach is the opposite: start with one contained use case where the data is good enough, prove it under real governance, and let scaling follow the evidence. The first use case is chosen precisely because it fits your current processes. You do NOT have to fix everything first.
CHECKDoes starting deliberately small change how heavy this feels?

IT ownership: "IT owns governance, no vendor-led roadmap"

"We're cautious about making sure IT owns the governance piece. We don't want a vendor-led roadmap that sidelines our internal teams."
ACKNOWLEDGEGood. That's exactly how it should be. This fails without IT leading it.
CLARIFYYou mentioned Liam. Would he be the natural owner, and who else on the IT side would want in from day one?
REFRAMEOur role is to help Liam and his team lead this safely, not to route around them. They define the guardrails, the access, the audit requirements. Asteron owns the governance; we enable it. The discovery session is designed with IT as co-owner, not spectator.
CHECKWould it make sense for Liam to co-own the session agenda with you?

Readiness: "We're not modern / cloud enough" (raised less often)

ACKNOWLEDGEA lot of manufacturers assume AI is a cloud-only conversation.
REFRAMERoadmap and process discovery can start right now, from your systems as they are. Full cloud readiness is not a prerequisite for planning; it's one of the things the plan accounts for.
CHECKDoes that change the picture on timing?
05

The Close

Metric 5 · all five steps, in order

Step 1: Summarize her needs + the starting use case

Let me play back what I heard, and correct me where I'm off. Leadership wants a credible AI position, the biggest daily drain is manual exception chasing with inventory visibility close behind, your systems are a patchwork where the data needs validating first, and anything we do has to be practical, low-disruption, and owned by your team with IT holding governance. The most sensible starting point is the exception-chasing assistant, done small and governed.
"That's a fair summary. I'd add we're cautious about IT owning the governance piece... Other than that, you've got it."

She WILL add the IT caveat. Respond: "Completely agree, and that's why I'd want Liam co-owning the session."

Step 2: Confirm interest before asking

Before I suggest anything: does that direction actually feel worth exploring to you?
"It does. But I'd want to loop in IT and one or two others who really understand the data and day-to-day pain... it needs to be a focus session with the right people."

Low pressure, never assumed. Wait for the yes; she gives it with conditions, which is a yes.

Step 3: Propose the specific session

Then here's the next step I'd suggest: a focused working session, about 90 minutes, with a concrete purpose: validate what data you can trust and where the gaps are, which you called your big unknown, prioritize the exception-chasing use case, and agree the governance and success measures with Liam in the room. You'd walk out with the skeleton of an answer for your leadership. No fluff, no pitch.

The next step must be NAMED and tied to current-state validation, use-case prioritization, governance, or success measures. Notice this quotes her own words back: "big unknown," "focus session," "no fluff." Every condition she set becomes part of your proposal.

Step 4: Name the attendees

For the room: you, Liam from IT as co-owner, and the one or two people you mentioned who really know the data and day-to-day pain. If budget questions will come up, someone from finance, but that's your call.
"That group sounds about right. I'll need to check availability. If you can send me a clear agenda and what prep is needed, I can start lining people up."

Step 5: The calendar lock (where most attempts fall short)

"Next week could work, but I'll need to confirm with Liam and the others first. If you send over the agenda, I'll take a look and get back to you. No promises yet."

Do not end on "sounds good, I'll send it over." Convert her deflection into a two-way commitment:

Perfect, that works. Here's what I'll do: I'll send you the draft agenda by Friday, including the prep, which is light, so nobody gets stretched. Once you've reviewed it with Liam, could you send me two or three times that work next week? Then I'll send the calendar invite to lock it in. Sound fair?

My action + my deadline (agenda by Friday) → her small action + timing (2-3 slots after Liam review) → the lock (calendar invite). Owners and timing on both sides, tone stays easy. That's the structure the rubric rewards.

Landmines

what reduces cooperation
  • Nodding past the "tools that throw answers" line. The #1 landmine. It's a scored objection wearing a compliment.
  • Ending the call on her homework deflection. "Send me the agenda and I'll get back to you" needs the two-way convert, every time.
  • Hype language. "Revolutionary," "game-changing." Instant tune-out.
  • Unsupported metrics. The approved-style proof point uses no numbers; keep it that way unless you hedge with "we'd validate first."
  • Assuming her ERP / cloud / data maturity. Even though she'll tell you it's a patchwork, still ask what needs validating.
  • Anything that smells vendor-led. She says it directly: no roadmap that sidelines internal teams. Liam co-owns or it dies.
  • Ignoring her workload condition. Mention light prep and low disruption in the close; she flags team bandwidth more than once.
  • Vague closes. "I'll send over some information" gets coached unless the whole call earned it.

Live Rubric Tracker

70% = pass · 27 items · red bars = commonly missed
0% · 0/27

Objection items start checked because the rubric marks them TRUE automatically if the concern never comes up. The chatbot item starts unchecked because Maya reliably raises it. Red-barred items are the ones most commonly missed; watch their triggers.

Metric 1 · Consultative Discovery & Agenda

Metric 2 · Plain-Language AI Explanation

Metric 3 · Use-Case Framing & Proof Points

Metric 4 · Objection Handling auto-TRUE if not raised

Metric 5 · Next Steps & Stakeholder Alignment