Enterprise Discovery Blueprint: AI Ticketing + SAP The central mistake to avoid here is treating “SAP is hard for users” as the business problem. That is a symptom. The discovery call needs to determine whether the underlying issue is actually user friction, support workload, process inefficiency, poor SAP adoption, data-entry errors, slow resolution, or some combination—and whether fixing it is financially meaningful enough to justify an AI layer. STEP 1 — Define the Discovery Objective The real objective The salesperson needs to answer one fundamental question: Is there a sufficiently expensive and urgent business problem caused by the way users interact with SAP that an AI ticketing layer could solve better than the alternatives? The discovery should therefore establish five things: What users struggle with in SAP What that struggle costs the business Whether an AI ticketing layer could realistically eliminate or reduce the cost Whether there is a compelling reason to act now Whether the organization can actually buy and implement the solution Must-know vs. nice-to-know Area Must Know Nice to Know Business pain What users struggle with and why Every individual complaint Financial impact Cost of support, delays, errors, productivity loss Perfectly precise ROI Operational impact Volume, frequency, teams affected Every workflow variation Current solution How tickets/support are handled today Complete history of every tool Future state What they want users/support teams to do differently Every desired feature Urgency Why change would happen now General strategic ambitions Inaction What happens if nothing changes Hypothetical long-term effects Buying criteria What must be true to purchase Every preference Decision process Who decides, approves and blocks Full organizational chart Stakeholders Users, IT/SAP, business owner, procurement/security Every possible stakeholder Budget Whether funding exists/is obtainable Exact budget too early Competition Build, improve SAP, service desk, other vendors, status quo Every competitor Resistance Integration, security, AI concerns, ownership Minor objections Implementation SAP architecture, integration, deployment requirements Technical details irrelevant to qualification STEP 2 — Buyer Hypothesis Known facts From the information provided, we know: The proposed product is an AI-operated ticketing tool. It is intended to be coordinated/integrated with SAP. The prospect perceives SAP as very difficult for users. Everything beyond this requires validation. Preliminary hypothesis Problem Users may struggle to navigate SAP, understand processes, complete tasks, find information, or resolve issues independently. That may generate a secondary problem: Users need help → support requests/tickets increase → support personnel spend time handling repetitive SAP-related questions → resolution takes time → employees remain blocked or inefficient. Why the problem might exist Possible causes include: SAP's complexity Poor user experience Insufficient training Lack of contextual guidance Poor documentation Complicated workflows Multiple systems/processes Users not knowing where to find information Support teams becoming the "human interface" to SAP These are hypotheses, not established facts. Who may be affected Potentially: SAP end users Finance Procurement Operations HR Customer service Warehouse/logistics Internal IT/help desk SAP support team SAP administrators Managers responsible for affected departments The discovery should identify which groups actually experience the problem. What they may be doing today Possible current approaches: IT/service desk tickets Email Phone/Teams/Slack Internal documentation SAP super-users Training Consultants Manual support Existing ticketing platform SAP-native functionality Again: do not assume which one applies. Potential cost of the current situation The economic case could come from: User productivity loss + support labor + resolution delays + errors + operational disruption + training burden. The important question is not: "How annoying is SAP?" It is: "What does SAP-related user friction cost the organization?" Potential trigger for change Possible triggers: SAP rollout or migration S/4HANA transformation Increasing SAP user population Growing support-ticket volume Service desk cost pressure Operational scaling New business units Poor adoption Leadership demanding automation AI transformation initiative Support-team capacity constraints Upcoming SAP project None should be presented as fact until validated. Potential reasons not to buy Problem isn't financially significant Existing service desk already solves it Better SAP training is sufficient Integration is too complex Security concerns around AI Data/privacy concerns Internal AI policy SAP strategy already addresses the problem Customer prefers building internally No budget No executive sponsor No urgency Too many stakeholders AI isn't trusted for operational workflows STEP 3 — Discovery Architecture Stage 1 — Opening Don't begin with: "I'd like to ask you some questions about your current process." That immediately creates an interrogation dynamic. Instead: "From what we've understood so far, the issue seems to be less about SAP itself and more about how difficult it can be for users to get things done or get help when they get stuck. I'd like to understand what that actually looks like in your organization, what it's costing you today, and then see whether there's a meaningful business case for changing it. If there is, we can work out what the next step should be; if there isn't, we'll know that too. Does that sound reasonable?" Then: "Perhaps we can start with how users currently deal with SAP when they can't complete something themselves." This establishes: purpose relevance permission business orientation no forced conclusion Stage 2 — Current Situation Question 1 "When an employee gets stuck in SAP today, what actually happens from the moment they realize they need help?" Why: Reveals the actual workflow rather than asking the prospect to characterize it. Strong answer: "They contact the service desk, create a ticket, and often someone from the SAP team has to intervene." Follow-up: "And where does that process tend to break down or create unnecessary work?" Question 2 "What types of SAP-related issues generate the most support demand?" Why: Determines whether the problem is repetitive and automatable. Listen for: repetitive questions navigation transactions permissions errors "how do I..." status requests process explanations Question 3 "Roughly how much of your support volume is related to people struggling to use SAP, rather than SAP itself being technically broken?" This is an extremely important distinction. You want to separate: technical SAP problems from human interaction problems. The AI solution may be highly relevant to the second category and much less relevant to the first. Question 4 "Who absorbs most of the effort when users can't resolve these issues themselves?" Possible answers: service desk SAP team business super-users managers consultants This starts establishing the economic impact. Stage 3 — Pain The salesperson should use: Problem → Cause → Frequency → Impact → Consequence Suppose the prospect says: "Users constantly need help with SAP." Don't immediately ask: "How many tickets?" Instead: Problem "What are users typically trying to accomplish when they need that help?" Cause "What makes those tasks difficult for them—finding the right transaction, understanding the process, knowing what information to enter, or something else?" Frequency "Is this something that happens occasionally, or is it part of the normal weekly support workload?" Impact "When someone gets stuck, what happens operationally? Do they wait for support, stop working, switch to another task, or create a workaround?" Consequence "And when that happens repeatedly across the organization, what does that ultimately affect?" This is much more powerful than: "How much time do tickets take?" because it reveals the business chain of consequences. Stage 4 — Business Impact This is probably the most important section of the call. Support-side economics Ask: "How much support capacity is currently being consumed by SAP questions that aren't really technical incidents?" Then: "What does that mean in terms of the team's capacity for higher-value work?" If they can quantify: "We have four people spending roughly 30% of their time on these requests." You now have the beginnings of an economic case. User productivity Ask: "When someone is waiting for help with SAP, how long are they typically blocked?" Then: "What does that person normally do during that time?" And: "Is the impact mainly lost productivity, delayed processes, or does it sometimes affect customers or revenue-generating activity?" The final question is crucial. A five-minute inconvenience is not necessarily an enterprise problem. A five-minute delay multiplied across 10,000 employees every week might be. Error costs Ask: "Do users sometimes work around the problem themselves rather than waiting for support?" If yes: "What kinds of errors or downstream problems can those workarounds create?" This could reveal: incorrect data duplicate work financial errors compliance risk delayed orders incorrect inventory manual corrections That can dramatically strengthen the business case. Management impact An overlooked question: "Who inside the organization is currently paying the price for this problem?" Not financially necessarily. You want to identify where the pain is visible. For example: CIO sees support costs COO sees operational delays CFO sees process inefficiency department managers see lost employee productivity SAP team sees support overload That helps identify the eventual buyer. Stage 5 — Desired Future State Do not ask: "Would you like an AI-powered ticketing system?" That's vendor-led discovery. Instead: "If you could redesign the experience for someone who gets stuck in SAP, what would you want to happen instead?" This produces a buyer-defined outcome. Then: "What would you want the user to be able to resolve without involving another person?" And: "What would you want the support team to stop having to do?" Excellent because it creates two measurable outcomes: User outcome Less friction / faster resolution / greater autonomy. Support outcome Fewer repetitive requests / lower workload / higher-value work. Then: "How would you know six months after implementation that the change had actually worked?" This produces success criteria. Stage 6 — Urgency The critical question: "Why is this something you're looking at now rather than six or twelve months from now?" If they have a strong answer, investigate it. "What's happening that makes the current situation less acceptable now?" Then: "What happens if nothing changes?" And: "Who inside the business is pushing for this to improve?" Strong urgency "We're migrating 5,000 additional users to SAP next year." Excellent. Weak urgency "We're always interested in improving efficiency." Potential deal risk. The salesperson should not manufacture urgency where none exists. STEP 4 — Decision-Making Analysis The salesperson needs to map the buying system. Champion Potential champion: Person who experiences the problem, believes the solution is valuable, and is willing to help navigate the organization. Ask: "Who is most motivated internally to see this problem solved?" Then: "If we identified a strong business case, who would be willing to help drive it internally?" A real champion does more than say: "This looks interesting." They provide: internal information access to stakeholders political guidance feedback introductions support for the business case Economic Buyer Likely candidates could include: CIO Head of IT Service Desk Director SAP Director COO transformation leader But don't assume. Ask: "Whose budget would ultimately fund something like this?" Then: "Who would need to believe the financial case is strong enough to approve it?" Decision Maker "Apart from yourself, who would need to be comfortable with the solution before a decision could be made?" Influencers Potential: SAP team IT architecture security procurement legal data protection business-unit leaders service desk Blockers Ask: "Who could stop this from moving forward even if the business users wanted it?" This is much better than: "Who are the stakeholders?" because it explicitly identifies veto power. STEP 5 — Qualification Framework Category What we need to learn Best question Positive signal Negative signal Pain Is SAP-related user friction material? "Which user problems create the most support demand?" Recurring, measurable problem Minor annoyance Impact Does it have economic consequences? "What happens when users can't resolve these issues?" Productivity/support cost/errors No measurable consequence Urgency Why change now? "Why address this now?" Migration, growth, cost pressure, deadline "Just exploring" Authority Can this person drive it? "Who ultimately approves this?" Clear decision path Unknown/hidden Budget Is funding realistic? "How are initiatives like this normally funded?" Existing initiative/budget No funding mechanism Fit Can AI address the actual problem? "Which problems would you want automated?" Repetitive, predictable support Mostly complex technical incidents Timeline When must outcome occur? "Is there a business date this needs to align with?" Defined target No timeframe Competition What alternatives exist? "What options are you considering besides adding a new platform?" Status quo has recognized weakness Existing solution clearly adequate Implementation Can it realistically deploy? "What would need to be true technically and organizationally for this to go live?" Clear SAP/integration path Major unresolved architecture/security issue Champion Is someone internally advocating? "Who would own driving this internally?" Named advocate Nobody owns it STEP 6 — Question Sequencing The call should progress approximately like this: 1. Context "When someone gets stuck in SAP today, what happens?" ↓ 2. Workflow "Who gets involved?" ↓ 3. Problem "Which types of issues create the most demand?" ↓ 4. Root cause "Why can't users resolve those issues themselves?" ↓ 5. Scale "How frequently does this happen?" ↓ 6. Operational impact "What does that cause for the user and support team?" ↓ 7. Business impact "Where does that ultimately show up for the business?" ↓ 8. Existing solution "What have you already done to address it?" ↓ 9. Limitations "What's still not being solved?" ↓ 10. Future state "What would you want the experience to look like instead?" ↓ 11. Success "How would you measure whether the change worked?" ↓ 12. Urgency "Why solve it now?" ↓ 13. Decision process "Who else needs to be involved?" ↓ 14. Implementation "What technical or organizational constraints could prevent this?" ↓ 15. Next step Only now should the salesperson discuss a concrete evaluation. STEP 7 — High-Value Follow-Ups These are designed to turn vague statements into business intelligence. Prospect: "It's inefficient." Don't ask: "How inefficient?" Ask: "Where does the inefficiency actually occur—from the user needing help, to someone responding, to resolving the issue?" Then: "Which part consumes the most organizational effort?" Prospect: "Users struggle with SAP." Ask: "What are they struggling to do?" Then: "What do they do when they can't figure it out?" Then: "Who has to step in?" Then: "How often does that happen?" Then: "What happens if that person isn't available?" You've now moved from complaint → workflow → dependency → business consequence. Prospect: "We get lots of tickets." Ask: "What percentage would you describe as genuinely technical incidents versus questions users could potentially resolve themselves?" Then: "Which category is most repetitive?" Then: "If you eliminated that category, what would the support team gain?" Prospect: "Our support team is overloaded." Ask: "What's consuming their capacity that you would most like to remove?" Then: "What would those people work on instead?" This establishes the opportunity cost. Prospect: "We need automation." Ask: "What business problem are you expecting the automation to solve?" Then: "What would improve if that process were automated?" This prevents the conversation from becoming feature-driven. STEP 8 — Buyer Psychology Strong Buying Signals Statements such as: "We're already looking for a solution." "This is becoming a problem at our current scale." "Our service desk can't keep up." "We're migrating another X users." "Our SAP team is spending too much time on this." "We have an initiative around reducing support costs." "If we could automate X, it would make a significant difference." Response Don't immediately pitch. Ask: "Which part of that is creating the greatest business pressure?" Pain Signals Listen for: repeated complaints escalating tickets support overload user frustration workarounds delays manual intervention management complaints expensive consultants repeated training Response Quantify the consequence. Urgency Signals Look for: SAP migration implementation deadline growth organizational expansion service-desk cost reduction executive mandate user-volume increase transformation program Response Connect the solution to the event: "So the reason timing matters is that this needs to be solved before [event]. What happens if it isn't?" Champion Signals A strong champion says things like: "I can introduce you to our SAP director." or: "I'll get our security person involved." or: "Let me show you our ticket data." That is far stronger than: "I'll discuss it internally." Response Give the champion something to carry internally: quantified problem business case implementation requirements success criteria stakeholder-specific value Risk Signals Listen for: "We'd have to get everyone comfortable with AI." "Security might be difficult." "SAP owns this." "We're already evaluating something." "We don't have a budget yet." "We're not sure who owns this." "We'd have to build a business case." These aren't necessarily objections. They are things that need to be diagnosed. Ask: "Which of those do you think is most likely to prevent the project?" Fake Interest Signals These are particularly dangerous: "Send me some information." "This looks really interesting." "Let's stay in touch." "We'll discuss it internally." "Can you send pricing?" "I'd like to see a demo." None necessarily means buying intent. Stronger test Ask: "Assuming the solution addresses the problem we've discussed, what would need to happen internally before you could actually move forward?" If they cannot articulate the path, qualification is incomplete. STEP 9 — Discovery Call Scorecard 100-point model Category Weight Business pain 15 Quantifiable impact 20 Urgency 15 Solution fit 15 Decision access 10 Champion strength 10 Implementation feasibility 5 Budget/funding path 5 Competitive position 5 Total 100 80–100 — Strong opportunity Characteristics: significant recurring problem measurable economic impact clear reason to act strong fit identified decision process internal advocate credible implementation path Action: advance toward a business-case/pilot/evaluation conversation. 60–79 — Potential opportunity Something important remains unresolved. Typical examples: impact not quantified no economic buyer urgency moderate integration questions unclear budget Action: don't demo your way out of uncertainty. Resolve the biggest unknown. 40–59 — Weak opportunity Potential problem exists but: impact is small urgency is low solution fit is questionable ownership unclear Action: continue only if a specific qualification gap can realistically be resolved. 0–39 — Poor opportunity Typical situation: SAP is annoying but not materially costly no urgency no owner no business impact no funding path solution doesn't fit status quo is acceptable Action: disqualify or nurture. STEP 10 — The Biggest Unknown The most important unanswered question is: "What measurable business consequence does SAP user difficulty create today, and is that consequence large enough that the organization is willing to invest to remove it?" This is more important than: number of tickets desired features budget integration architecture AI preferences because without economic pain, everything else becomes secondary. If positive If the prospect says: "This consumes 3,000 support hours annually and delays operational processes." You potentially have a serious enterprise business case. The conversation becomes: problem → economics → solution → implementation → decision. If negative If they say: "It's frustrating, but it doesn't really affect productivity or cost." Then the opportunity may be fundamentally weak. The salesperson shouldn't manufacture a business case. How to uncover it Ask: "If you had to explain to your CFO why solving this deserves investment, what would you point to?" That's an excellent enterprise question. If the prospect struggles to answer, that itself is valuable information. STEP 11 — Closing the Discovery Don't end with: "I'll send you some information." Instead, summarize what you've learned. Recommended verbal summary "Let me make sure I've understood this correctly. Today, users are struggling with [specific SAP problem], which means [specific workflow consequence]. That creates [support workload/productivity loss/errors/delay], and the biggest business impact appears to be [quantified consequence]. What you'd ideally want is [desired future state], with success measured by [metric]. The reason this is worth looking at now is [trigger/deadline/business event]. Before we can determine whether there's a real case for moving forward, we still need to understand [remaining unknown], and we'd also need to involve [stakeholders]. Based on what we've discussed, I don't think another generic demo is the most useful next step. I think the better next step would be [specific next step], where we can validate [business/technical hypothesis]. If that checks out, then we can determine whether there's a legitimate business case for moving forward." This is consultative rather than transactional. Recommended next steps by deal stage Problem identified but economics unclear Next step: quantify ticket volume, support hours, affected users and delays. Economic case emerging Next step: business-case workshop with business owner + IT/SAP. Strong business case + technical uncertainty Next step: technical validation / integration workshop. Strong business + technical case Next step: controlled pilot with agreed success metrics. Pilot successful Next step: executive/business case + procurement/security + rollout plan. STEP 12 — What NOT to Ask ❌ "What keeps you up at night?" Too generic. Better: "Which consequence of the current SAP support process is most problematic for the business?" ❌ "What are your biggest challenges with SAP?" Likely produces a laundry list. Better: "When users can't complete something in SAP, what happens operationally?" ❌ "How many tickets do you receive?" Ticket volume alone doesn't establish value. Better: "Which portion of those tickets could potentially be resolved without human intervention, and what does handling those requests currently consume?" ❌ "What's your budget?" Too early. It can make the prospect defensive before value is established. Better: "How are initiatives aimed at reducing support workload or improving SAP adoption normally funded?" ❌ "Would you be interested in AI?" You're asking them to validate your technology. Better: "Which parts of the current user-support process would you most want to remove or automate?" ❌ "What features are important to you?" Feature shopping encourages commodity comparison. Better: "What would the solution need to accomplish for you to consider the project successful?" ❌ "Who is the decision maker?" Can sound like sales qualification. Better: "Who would need to be comfortable with this from a business, technical, security and financial perspective before you could proceed?" STEP 13 — Final One-Page Discovery Blueprint CALL OBJECTIVE Determine whether SAP user difficulty creates a material, measurable and urgent business problem that an AI ticketing layer can credibly solve. BUYER HYPOTHESIS Known: SAP is perceived as difficult for users and an AI ticketing tool is being considered. Hypothesis: User friction may create excessive support demand, productivity loss, delays and/or errors. Must validate: scale, economic impact, root cause, urgency and whether AI is actually the appropriate solution. 5 MUST-KNOW QUESTIONS "When someone gets stuck in SAP today, what happens from that point onward?" "Which types of problems create the most support demand?" "What does that demand actually cost the organization—in support capacity, user productivity, delays or errors?" "If you could redesign that experience, what would you want users and the support team to do differently?" "Why is solving this important now rather than later?" 5 HIGH-VALUE FOLLOW-UPS "What happens next?" "Who has to get involved?" "How often does that happen?" "What does that prevent them from doing?" "If nothing changed, what would that mean six or twelve months from now?" These are powerful because they repeatedly move the conversation toward consequences. KEY BUYING SIGNALS Quantified support burden Significant affected user population Repetitive problems Executive pressure SAP expansion/migration Clear cost/productivity impact Existing initiative Named internal champion Willingness to involve stakeholders Willingness to share operational data KEY RED FLAGS "It's annoying but not really costly." No measurable impact No urgency No owner No budget mechanism Existing solution already works Problem is primarily technical SAP failure AI cannot realistically solve the identified problem Security/integration appears impossible Prospect refuses access to relevant stakeholders DECISION-MAKING QUESTIONS "Who owns this problem?" "Who benefits most if it's solved?" "Whose budget would fund it?" "Who can veto the project?" "Who needs to approve security and integration?" "Who should be involved in evaluating the solution?" "What does the procurement process look like?" URGENCY QUESTIONS "Why now?" "What's changed?" "Is there a deadline this needs to align with?" "What happens if you don't solve it?" "Is there an upcoming SAP rollout, migration, growth initiative or cost-reduction target?" "Who is pushing for this internally?" BUSINESS-IMPACT QUESTIONS "How much support capacity is consumed by these requests?" "How long are users typically blocked?" "What happens to the work they're trying to complete?" "Do these problems create errors or rework?" "What happens when support isn't available?" "What would the organization gain if this workload disappeared?" "If you had to justify the investment to the CFO, what would the business case be?" NEXT-STEP STRATEGY Do not automatically schedule a demo. Match the next step to the unresolved risk: Economic uncertainty → quantify impact. Business case established → involve economic buyer. Technical uncertainty → SAP/integration workshop. Strong fit + measurable case → controlled pilot. No meaningful impact/urgency → disqualify or nurture. DISQUALIFICATION CRITERIA Consider walking away when: The problem is primarily inconvenience. There is no meaningful financial/operational consequence. The prospect cannot identify an owner. There is no reason to change now. The current solution is adequate. AI is not appropriate for the actual problem. Implementation requirements make the economics unattractive. No credible funding path exists. The prospect will not provide access to necessary stakeholders. The organization wants a demo but cannot articulate a business problem. BIGGEST UNKNOWN Is SAP user friction merely annoying—or is it creating enough measurable economic damage that the organization has a compelling reason to invest in fixing it now? That is the question the entire discovery should progressively answer. The strongest salesperson will not leave this call knowing everything. They will leave knowing whether this is a real problem, how expensive it is, why it matters now, who owns it, and what must happen next.