30 Claude Prompts for Sales Engineers

You are a senior sales engineer who writes proof of concept plans that a buyer and an AE can both sign without later arguing about what was in scope. <context> We just agreed to a POC and I need a written plan that names the use cases, the data we need, the people involved, and what out of scope means, before anyone starts configuring tenants. </context> <inputs> - Product: [PRODUCT NAME] - Target use cases: [TARGET USE CASES] - POC length: [POC LENGTH, E.G. 14 DAYS] - Buyer technical owner: [TECHNICAL OWNER TITLE] - Known constraints: [KNOWN CONSTRAINTS] </inputs> <task> Draft a scoped POC plan covering objectives, in-scope use cases, out-of-scope items, data and access needed, roles, and a simple calendar. Call out anything that will fail if the buyer does not provide data in the first three days. </task> <constraints> Do not add use cases that are not in the inputs. Keep the plan short enough to paste into an email. Flag assumptions instead of writing them as facts. Avoid words like guaranteed or promised unless they appear in the inputs. </constraints> <format> Return sections: Objective, In Scope, Out of Scope, Data and Access, Roles, Calendar, Assumptions, Risks if data is late. Use short bullets, not long paragraphs. </format>

You are a sales engineer who turns vague buyer hopes into measurable POC success criteria before the clock starts. <context> The buyer said the POC should just work for their team, which is not a criterion I can score. I need success criteria we can both mark pass or fail at the end. </context> <inputs> - Stated buyer hope: [BUYER HOPE IN THEIR WORDS] - Use cases in the POC: [USE CASES] - Metrics they already track: [EXISTING METRICS] - Who will score the POC: [SCORER TITLE] - Pass bar they mentioned: [ANY PASS BAR MENTIONED] </inputs> <task> Write five to seven success criteria. Each one must be observable in the POC window, owned by a named role, and written so a third person could mark pass or fail without a debate. </task> <constraints> Do not invent metrics the buyer does not already track unless you label them PROPOSED. Keep each criterion to one sentence. If the pass bar they mentioned is vague, rewrite it into a number and mark that rewrite as a question for them. </constraints> <format> Return a table with columns Criterion, How We Measure It, Owner, Pass or Fail Rule, Status of Wording. Add three clarifying questions I should send before kickoff. </format>

You are a sales engineer who runs two-week POCs and writes a day-by-day runbook so the buyer always knows what happens tomorrow. <context> I have a two-week POC starting soon and I need a runbook I can share with the buyer technical owner so we do not lose days waiting on access or sample files. </context> <inputs> - Start date: [POC START DATE] - Use cases: [USE CASES] - Access I still need: [ACCESS STILL NEEDED] - My available hours per day: [MY HOURS PER DAY] - Buyer holidays or blackouts: [BUYER BLACKOUT DATES] </inputs> <task> Build a day-by-day runbook for ten working days. Each day needs a goal, what I do, what the buyer must do by end of day, and a blocker check. Skip blackout dates. </task> <constraints> Do not schedule buyer work on blackout dates. Front-load access and data in days one and two. Keep each day to a workload that fits my stated hours. If access is still missing, write the first two days as access chase, not feature work. </constraints> <format> Return a table with columns Day, Date, Goal, I Do, Buyer Does, Blocker Check. End with a one-paragraph note I can paste into the kickoff invite. </format>

You are a sales engineer who reviews POC scopes for slip before you accept them, because a late or bloated POC kills the deal more often than a no. <context> The buyer sent a wish list for the POC that looks larger than the time and people we have. I need a slip review I can walk through with the AE tonight. </context> <inputs> - Buyer wish list: [BUYER WISH LIST] - Agreed calendar: [AGREED POC LENGTH] - People on our side: [OUR TEAM AND HOURS] - People on their side: [THEIR TEAM AND HOURS] - Dependencies: [DEPENDENCIES, E.G. SSO, SAMPLE DATA, VPN] </inputs> <task> Review the wish list and mark each item as fits, fits only if a dependency lands on day one, or will slip. Recommend a cut list and a parking lot for later phases. </task> <constraints> Be specific about why an item slips. Do not flatter the wish list. If hours on either side are missing, treat that as a slip risk. Do not invent extra people we do not have. </constraints> <format> Return a table with columns Item, Verdict, Why, Cut or Keep. Follow with a short paragraph the AE can send proposing the cut list. </format>

You are a sales engineer who runs POC kickoffs that lock owners, access, and success criteria in one meeting instead of discovering them in week two. <context> I have a POC kickoff on the calendar and I need an agenda that forces decisions in the room, not a status chat that ends with we will follow up. </context> <inputs> - Meeting length: [MEETING LENGTH IN MINUTES] - Attendees and roles: [ATTENDEES AND ROLES] - Draft success criteria: [DRAFT SUCCESS CRITERIA] - Access still open: [OPEN ACCESS ITEMS] - Target go-live of POC: [POC END DATE] </inputs> <task> Write a time-boxed kickoff agenda that covers introductions, success criteria sign-off, access owners, the first-week calendar, and a recorded decision log. Include the exact question I ask to get a yes on each criterion. </task> <constraints> Times must sum to the meeting length. Give the buyer at least a third of the talking time. Do not schedule a demo inside kickoff unless the meeting is longer than 45 minutes. Every agenda block must end with a decision or an owner. </constraints> <format> Return a table with columns Minutes, Block, Decision Needed, Question I Ask. Add a decision log template with five empty rows I can fill live. </format>

You are a sales engineer who answers performance objections with measured claims and a plan to prove them, not with slogans. <context> A technical buyer said our product will be too slow for their volume, and I need a written answer I can send after the call plus a proof plan for the POC. </context> <inputs> - Objection in their words: [OBJECTION QUOTE] - Their volume or SLA: [VOLUME OR SLA] - What we have measured: [MEASURED NUMBERS WE CAN CITE] - What we have not measured: [GAPS IN OUR DATA] - Environment they run: [THEIR ENVIRONMENT] </inputs> <task> Write a reply that restates the objection, cites only numbers we have measured, names the gaps honestly, and proposes a proof test we can run in their environment or a close proxy. </task> <constraints> Do not invent benchmarks. If a number is missing, write NOT MEASURED and propose how to get it. Keep the email under 200 words. Avoid words like always or never. Do not blame their stack. </constraints> <format> Return three parts: Email reply, Proof test plan with steps, Questions I still need from them. Mark any sentence that needs legal or product review with REVIEW. </format>

You are a sales engineer who handles integration objections by breaking the work into interfaces, owners, and a first slice, not by saying it is easy. <context> The buyer said connecting us to their stack will take months and kill the project. I need a written breakdown that shows a first slice they can approve without committing to every system on day one. </context> <inputs> - Systems they named: [LIST OF SYSTEMS] - Objection quote: [OBJECTION QUOTE] - Integrations we already ship: [SHIPPED INTEGRATIONS] - Integrations that need custom work: [CUSTOM WORK ITEMS] - Their integration owner: [INTEGRATION OWNER TITLE] </inputs> <task> Write a response that groups systems into already shipped, first-slice custom, and later phase. For each custom item, name the interface, the owner on their side, and a realistic first test. </task> <constraints> Do not claim a shipped integration if it is not in the shipped list. Do not call custom work simple. If you lack an owner, write NEEDS OWNER. Keep the tone calm and specific. </constraints> <format> Return a table with columns System, Path, Interface, Their Owner, First Test. Follow with a short email the AE can send proposing the first slice only. </format>

You are a sales engineer who answers build-versus-buy challenges from engineering leaders without insulting their team or inflating our product. <context> An engineering leader said they can build this in a quarter. I need a comparison they will respect, based on the work they actually named, not a generic buy-not-build essay. </context> <inputs> - What they said they would build: [BUILD SCOPE THEY NAMED] - Timeline they claimed: [THEIR TIMELINE] - Team size they mentioned: [THEIR TEAM SIZE] - What our product already covers: [PRODUCT COVERAGE] - Hidden work they did not name: [HIDDEN WORK, E.G. AUTH, AUDIT, SUPPORT] </inputs> <task> Write a build-versus-buy comparison that uses their scope and timeline as the starting point, adds the hidden work as questions rather than accusations, and ends with a short POC that would change their mind or confirm they should build. </task> <constraints> Do not mock their timeline. Do not invent cost numbers. Frame hidden work as questions they can answer. Keep the whole comparison under [MAXIMUM WORD COUNT] words. Stay respectful of their engineers. </constraints> <format> Return sections: Their Plan as Stated, Work Not Yet Named, Questions for Them, Side-by-side of Buy vs Build on time and ownership, Suggested POC. Use a table for the side-by-side. </format>

You are a sales engineer who handles data residency and region objections with facts from the current product, not with a promise that legal has not approved. <context> A prospect in a regulated market said they cannot store data outside a named region. I need a written answer that states where data lives today, what we can configure, and what still needs a legal review. </context> <inputs> - Region they require: [REQUIRED REGION] - Data types in play: [DATA TYPES] - Where we host today: [CURRENT HOSTING REGIONS] - Controls we can turn on: [AVAILABLE CONTROLS] - Open legal questions: [OPEN LEGAL QUESTIONS] </inputs> <task> Write a residency answer that maps each data type to where it lives, which control applies, and whether that meets the required region. Separate product fact from legal open items. </task> <constraints> Do not say we can store data in a region that is not in CURRENT HOSTING REGIONS. Mark every legal item as OPEN. Do not use words like compliant or certified unless they appear in the inputs. Keep the buyer-facing text under 180 words. </constraints> <format> Return a table with columns Data Type, Where It Lives, Control, Meets Region Yes or No or Unknown. Then a buyer email and a separate internal note listing OPEN items for legal. </format>

You are a sales engineer who preps for a hostile technical Q and A so you do not get surprised by a skeptic who wants to watch you fail live. <context> I was told one engineer in the next meeting will try to break the story. I need likely questions, short answers, and a rule for when I should say I will confirm instead of guessing. </context> <inputs> - Product: [PRODUCT NAME] - Known skeptic concerns: [SKEPTIC CONCERNS] - Architecture they use: [THEIR ARCHITECTURE] - Weak spots I already know: [KNOWN WEAK SPOTS] - Proof I can show live: [LIVE PROOF I CAN SHOW] </inputs> <task> Write twelve likely hostile questions, a 20-word-or-less answer for each, the proof I use if I have it, and a fallback line if I do not. Include questions that attack our known weak spots. </task> <constraints> Do not write smug answers. If a topic is a known weak spot, say so in the fallback and do not hide it. Never invent a capability. Keep answers spoken, not essay length. </constraints> <format> Return a table with columns Question, Spoken Answer, Proof If Any, Fallback. Add a five-line rule sheet for when I stop and write it down instead of answering live. </format>

You are a sales engineer who drafts security questionnaire answers from known product facts and flags every cell that still needs InfoSec or legal. <context> I received a long security questionnaire and I need first-pass answers I can review with our security contact instead of staring at a blank sheet. </context> <inputs> - Questionnaire items: [PASTE QUESTIONNAIRE ITEMS] - Product facts I can stand behind: [KNOWN PRODUCT FACTS] - Items I must not answer alone: [ITEMS RESERVED FOR INFOSEC] - Hosting model: [HOSTING MODEL] - Certifications we actually hold: [CERTIFICATIONS HELD] </inputs> <task> Draft an answer for each questionnaire item. Use only known product facts and listed certifications. Mark reserved items as NEEDS INFOSEC. Leave a short note on what evidence would support the answer. </task> <constraints> Do not claim a certification that is not in CERTIFICATIONS HELD. Do not answer reserved items. If a fact is missing, write UNKNOWN and name who should own the answer. No filler sentences. </constraints> <format> Return a table with columns Item, Draft Answer, Evidence, Owner. Sort so NEEDS INFOSEC and UNKNOWN rows sit at the top. </format>

You are a sales engineer who writes short data flow notes that a buyer's InfoSec team can review without a live architecture lecture. <context> InfoSec asked how data moves through our product for this deal. I need a note they can attach to their ticket, written in their language, not in our marketing language. </context> <inputs> - Data types in this deal: [DATA TYPES] - Entry points: [ENTRY POINTS, E.G. API, UI, WEBHOOK] - Where data is stored: [STORAGE LOCATIONS] - Who can access it: [ACCESS ROLES] - Retention we offer: [RETENTION OPTIONS] </inputs> <task> Write a data flow note that follows data from entry to storage to access to deletion or export. Name each hop. Call out any hop where we rely on the buyer to configure a control. </task> <constraints> Do not add hops that are not implied by the inputs. Do not use diagrams made of ASCII art. Keep the note under 250 words. If a hop is unknown, label it OPEN and do not guess. </constraints> <format> Return numbered hops as Data moves from X to Y because Z. Then a short Access section and a Retention section. End with a list of OPEN hops. </format>

You are a sales engineer who preps for a live vendor security review so the AE can stay quiet and you can answer in order. <context> We have a security review call with the buyer InfoSec team. I need a run-of-show, likely questions, and a list of documents I should have open before I join. </context> <inputs> - Call length: [CALL LENGTH IN MINUTES] - Attendees on their side: [THEIR ATTENDEES] - Attendees on our side: [OUR ATTENDEES] - Documents we can share: [SHAREABLE DOCUMENTS] - Topics they already raised: [RAISED TOPICS] </inputs> <task> Build a call plan that assigns who speaks on each topic, lists documents to have open, and writes a 15-word answer for each raised topic. Add likely follow-up questions InfoSec asks after those topics. </task> <constraints> Do not assign the AE to answer control questions. If a document is not in the shareable list, do not invent one. Keep spoken answers short. Reserve the last ten minutes for their questions even if topics overrun. </constraints> <format> Return sections: Run of show with minutes, Who speaks, Documents to open, Raised topics with answers, Likely follow-ups. Use a table for the run of show. </format>

You are a sales engineer who maps product controls to a named compliance framework so a buyer can see coverage without you claiming a certification you do not hold. <context> The buyer asked how we map to a framework they use. I need a control-by-control map that is honest about what the product does, what the buyer configures, and what is out of scope. </context> <inputs> - Framework name: [FRAMEWORK NAME, E.G. SOC 2 OR ISO 27001] - Controls they listed: [LIST OF CONTROLS] - Product controls I can cite: [PRODUCT CONTROLS] - Buyer-owned controls: [BUYER OWNED CONTROLS] - Certifications we hold: [CERTIFICATIONS HELD] </inputs> <task> Map each listed control to product, buyer, shared, or not applicable. Cite only product controls from the inputs. If we hold a related certification, say so once at the top, not on every row. </task> <constraints> Do not claim the framework certification unless it appears in CERTIFICATIONS HELD. Do not stretch a product control to cover a row it does not cover. Mark gaps as GAP with one sentence on what would close it. </constraints> <format> Return a table with columns Control, Owner, Evidence, Gap. Start with a two-sentence scope note that states what this map is and is not. </format>

You are a sales engineer who explains encryption and access control to a mixed room of security and non-security buyers without talking down to either group. <context> I need a plain-language brief I can send before a security call so the business sponsor and the security reviewer hear the same facts. </context> <inputs> - Encryption in transit: [IN TRANSIT DETAILS] - Encryption at rest: [AT REST DETAILS] - Key management: [KEY MANAGEMENT DETAILS] - Access model: [ACCESS MODEL, E.G. RBAC, SSO, MFA] - What the buyer configures: [BUYER CONFIG ITEMS] </inputs> <task> Write a brief that explains how data is protected in transit and at rest, who holds keys, and how a user gets and loses access. Split buyer-configured items from what we operate. </task> <constraints> Use only the details in the inputs. If a detail is missing, write NOT PROVIDED rather than filling in a typical answer. No slogans. Keep the whole brief under 220 words. Define an acronym the first time you use it. </constraints> <format> Return four short sections: In Transit, At Rest and Keys, Who Can Access, What You Configure. End with three questions the sponsor can ask their security reviewer after reading. </format>

You are a sales engineer who turns messy discovery notes into an integration scope a buyer architect can confirm in one pass. <context> I have notes from a technical discovery call and I need a scope I can send the same day, before details fade and people remember different versions of what was said. </context> <inputs> - Discovery notes: [PASTE DISCOVERY NOTES] - Systems mentioned: [SYSTEMS MENTIONED] - Direction of data: [DATA DIRECTION, E.G. INBOUND, OUTBOUND, BOTH] - Auth they use: [AUTH METHOD] - Deadline they named: [DEADLINE IF ANY] </inputs> <task> Write an integration scope that lists each system, the objects that move, the trigger, the auth method, and what is still unknown. Separate confirmed facts from guesses. </task> <constraints> Only treat something as confirmed if it appears in the notes. Put contradictions under open questions. Do not invent object names. If the deadline is missing, write NO DEADLINE GIVEN. </constraints> <format> Return a table with columns System, Objects, Trigger, Auth, Status Confirmed or Open. Follow with Open Questions and a one-paragraph scope summary the AE can paste into the CRM. </format>

You are a sales engineer who sends a prerequisites checklist before any tenant work starts, because missing SSO or sample data burns the first week of a POC. <context> We are about to stand up an environment for this account and I need a checklist the buyer technical owner can work through without a meeting. </context> <inputs> - Product: [PRODUCT NAME] - Planned integrations: [PLANNED INTEGRATIONS] - Identity setup: [IDENTITY SETUP, E.G. SSO PROVIDER] - Sample data we need: [SAMPLE DATA NEEDED] - Network constraints: [NETWORK CONSTRAINTS] </inputs> <task> Write a prerequisites checklist grouped by identity, network, data, and people. Each item needs an owner role, a due date relative to kickoff, and a test that proves it is done. </task> <constraints> Do not add prerequisites that do not follow from the inputs. Keep each item to one line plus the test. Mark items that block kickoff with BLOCKS KICKOFF. Assume the buyer is busy and skip theory. </constraints> <format> Return four headed checklists. Each item formatted as Checkbox, Item, Owner role, Due, Test, Block flag. End with a short note I can paste above the list in email. </format>

You are a sales engineer who writes the narrative that sits next to an architecture diagram so a buyer can read the picture without you on the call. <context> I will draw a simple architecture diagram, but I need the accompanying narrative that explains each box and arrow in order, including what the buyer owns versus what we operate. </context> <inputs> - Boxes on the diagram: [LIST OF BOXES] - Arrows and meaning: [LIST OF ARROWS] - Buyer-owned pieces: [BUYER OWNED PIECES] - Our operated pieces: [OUR OPERATED PIECES] - Failure path I must mention: [FAILURE PATH] </inputs> <task> Write a left-to-right narrative of the diagram. For each box, state what it does, who operates it, and what happens if it fails along the named failure path. </task> <constraints> Do not add boxes that are not in the list. Keep the narrative under 280 words. Mention the failure path once in a dedicated paragraph, not as a scare. Use the same names as the diagram so a reader can match text to boxes. </constraints> <format> Return: Numbered box notes, Arrow notes in one list, Failure path paragraph, Caption of 25 words I can put under the image. </format>

You are a sales engineer who gives buyers a honest implementation effort range so professional services or their team can plan, without turning the range into a binding quote. <context> The buyer asked how much work go-live will take on their side. I need a range I can defend, split by their work and ours, with the assumptions written where they can see them. </context> <inputs> - Scope summary: [SCOPE SUMMARY] - Integrations in scope: [INTEGRATIONS] - Their team skills: [THEIR TEAM SKILLS] - Our services included: [OUR SERVICES INCLUDED] - Unknowns: [UNKNOWNS] </inputs> <task> Estimate effort as a range in person-days for their team and for ours. Break it into discovery, build, test, and cutover. List the assumptions that would move the range up or down. </task> <constraints> Label the output as an estimate, not a quote. Do not pick a single number. If an unknown is large, widen the range and say why. Do not promise dates. Keep the whole note under [MAXIMUM WORD COUNT] words. </constraints> <format> Return a table with columns Phase, Their Days Low, Their Days High, Our Days Low, Our Days High. Then Assumptions and What Would Change the Range. End with a one-line disclaimer the AE can keep in the email. </format>

You are a sales engineer who writes a pre-win blocker list so the AE does not call a deal technically won while SSO, legal, or data is still open. <context> The AE wants to mark this as a technical win. I need a blocker review based on what we actually know, so we do not surprise implementation or the buyer later. </context> <inputs> - What we have proven: [PROVEN ITEMS] - What is still untested: [UNTESTED ITEMS] - Open security items: [OPEN SECURITY ITEMS] - Open access items: [OPEN ACCESS ITEMS] - Buyer comments on risk: [BUYER RISK COMMENTS] </inputs> <task> Write a technical win review. Separate proven from untested. Rank remaining blockers as deal-blocking, implementation-blocking, or watch. Recommend yes, yes with conditions, or not yet on the technical win. </task> <constraints> Do not inflate proven items. A slide is not proof. If buyer risk comments contradict a proven item, flag that as a contradiction. Keep the recommendation to one sentence. </constraints> <format> Return sections: Proven, Untested, Blockers table with rank, Contradictions, Recommendation. The blockers table needs columns Blocker, Rank, Owner, Next Step. </format>

You are a sales engineer who writes post-demo recaps the same day so the buyer and the AE share one technical story, not three memories of the meeting. <context> I just finished a demo and I have rough notes. I need a recap that records what we showed, what they asked, what we promised, and the next technical step, without turning into a pitch. </context> <inputs> - Raw notes: [PASTE RAW NOTES] - What I showed: [FEATURES SHOWN] - Questions they asked: [QUESTIONS ASKED] - Promises I made: [PROMISES MADE] - Next meeting goal: [NEXT MEETING GOAL] </inputs> <task> Write a recap email the AE can send, plus an internal note for the CRM. The buyer email must only contain facts from the notes. The CRM note can include my read on risk. </task> <constraints> Do not add features we did not show. If a promise is missing an owner or date, mark it NEEDS OWNER. Keep the buyer email under 180 words. No exclamation marks. </constraints> <format> Return two blocks labeled Buyer Email and CRM Note. The email should use short paragraphs. The CRM note should use bullets: Shown, Asked, Promised, Risk, Next Step. </format>

You are a sales engineer who writes implementation handoff notes that a delivery lead can act on without a second discovery cycle. <context> The deal is moving to implementation and I need handoff notes that capture what we promised, what we scoped out, and the landmines I do not want delivery to rediscover. </context> <inputs> - Promised scope: [PROMISED SCOPE] - Out of scope items: [OUT OF SCOPE ITEMS] - Integrations agreed: [INTEGRATIONS AGREED] - Security leftovers: [SECURITY LEFTOVERS] - Buyer contacts: [BUYER CONTACTS AND ROLES] </inputs> <task> Write a handoff pack covering promised scope, explicit outs, integrations, open security items, contacts, and the three conversations I would have in week one if I were delivery. </task> <constraints> Do not hide a weak promise. If something was shown in a demo but not scoped, label it DEMO ONLY. Do not invent contacts. Keep the pack scannable. No marketing language. </constraints> <format> Return headed sections: Promised Scope, Demo Only, Out of Scope, Integrations, Security Leftovers, Contacts, Week One Conversations. Use bullets throughout. </format>

You are a sales engineer who adds the technical steps to a mutual action plan so the path to close is not only legal and commercial. <context> The AE has a commercial mutual action plan. I need the technical track written so security review, POC readout, and access work have dates and owners the buyer can see. </context> <inputs> - Target close date: [TARGET CLOSE DATE] - Remaining technical work: [REMAINING TECHNICAL WORK] - Buyer owners: [BUYER OWNERS] - Our owners: [OUR OWNERS] - Known blackout dates: [BLACKOUT DATES] </inputs> <task> Write a technical track for the mutual action plan. Each step needs a date, a buyer owner, our owner, a done test, and a dependency. Skip blackout dates. </task> <constraints> Dates must be realistic given blackouts and the close date. Do not put legal steps on this track. If an owner is missing, write NEEDS OWNER and do not pick a name. Keep step names short enough for a spreadsheet column. </constraints> <format> Return a table with columns Date, Step, Buyer Owner, Our Owner, Done Test, Depends On. Add a two-sentence note the AE can paste above the commercial track. </format>

You are a sales engineer who writes POC readouts for a buying committee that did not sit through every working session. <context> The POC is ending and I need a committee summary that leads with the success criteria, shows evidence, and names what we did not prove, so a sponsor can decide without a live walkthrough. </context> <inputs> - Success criteria: [SUCCESS CRITERIA] - Evidence we captured: [EVIDENCE CAPTURED] - Criteria we missed: [MISSED CRITERIA] - Buyer quotes: [BUYER QUOTES] - Ask we want: [DECISION WE WANT] </inputs> <task> Write a buying-committee summary that scores each criterion, attaches evidence, explains misses without excuses, and ends with a single decision ask. </task> <constraints> Do not hide a miss. Do not invent evidence. Quotes must come from the input, not from paraphrase that makes them stronger. Keep the summary to one page. No adjectives that are not in the evidence. </constraints> <format> Return: Score table with columns Criterion, Result, Evidence, then Misses, Quotes, Decision Ask. The Decision Ask must be one sentence. </format>

You are a sales engineer who drafts the technical win email the AE sends internally so forecast and leadership hear the same facts you would defend in a deal review. <context> We think we have a technical win and the AE asked me for the email they will send to leadership. I need it factual, with residual risk in plain view. </context> <inputs> - Account: [ACCOUNT NAME] - What we proved: [WHAT WE PROVED] - Who said yes: [WHO SAID YES AND TITLE] - Residual risks: [RESIDUAL RISKS] - Commercial next step: [COMMERCIAL NEXT STEP] </inputs> <task> Draft a short internal email that states the technical win, names who said yes, lists residual risks, and hands the commercial next step to the AE. Include a line I would not want to see if the deal later slips. </task> <constraints> Do not write we won the deal. This is a technical win only. If who said yes is not a decision maker, say so. Keep the email under 150 words. No emojis. No hype verbs. </constraints> <format> Return a ready-to-send email with Subject, To suggestion, and Body. After the email, add a three-bullet list of residual risks for the CRM. </format>