How to Run an AI Sales Cycle, From Discovery to Handoff

AI deals rarely die in the first meeting. They die in a pilot that never ends, a usage forecast nobody wrote down, or a security review that starts two weeks before quarter close. Each of those failures starts earlier in the cycle, when the account executive skipped a question the buyer would eventually need answered.

This playbook runs a deal in seven stages. Each stage has a job, a written output, and an exit gate: the condition that must be true before the next stage starts. It was assembled from public vendor documentation and practitioner write-ups, checked on September 26, 2026. It is a process to adapt, not a record of tested deals.

The seven stages at a glance

Stages 3, 4 and 5 should overlap. Start security review as soon as the buyer agrees to evaluate. Waiting for the evaluation to pass is the most common way to lose a quarter.

Stage 1: Discovery that finds the workflow

The goal of discovery is a specific workflow, not a general interest in AI. "We want to use AI in support" is not a deal. "Tier-one billing tickets take our team a day to answer, and we have a backlog every month-end" is the start of one.

A widely used qualification frame is MEDDICC: metrics, economic buyer, decision criteria, decision process, identified pain, champion and competition. For AI deals, add three questions to it:

• What have you tried already? Many buyers have run an internal prototype or a trial of another tool. What broke tells you what your evaluation must prove.
• Who judges output quality? Someone has to say whether an answer is right. Find that person now. It is often not the buyer.
• What happens when the model is wrong? The answer sets how much human review the workflow needs, which shapes both the evaluation and the price.

Output: discovery notes that separate what the buyer said from what you inferred. The prepare-discovery and qualify-opportunity skills in the site's open-source GTM skills are built around that separation.

Stage 2: Technical qualification

Technical qualification answers one question: can this customer actually use the product? Bring a sales engineer or forward deployed engineer to this call if your company has one.

Check four things.

1. Data. Where the data lives, what format it is in, and whether the customer can share a sample for the evaluation. Regulated data will change the timeline.
2. Integration. Which systems the product reads from and writes to, and who on the customer side owns them.
3. Deployment. Whether the customer requires a specific cloud, region, single-tenant deployment or their own model keys.
4. Volume. Rough request counts, document counts or conversation counts. You need this for Stage 4.

Output: a one-page fit summary that lists blockers plainly. A blocker you find now costs a call. One you find after the evaluation costs the deal.

Stage 3: Design the evaluation with the customer

This is the stage that separates AI selling from most software selling. The buyer cannot judge an AI product from a demo, because a demo shows the vendor's examples. They need to see it handle their own work. Current postings make the evaluation part of the AE's job: Perplexity's Commercial AE runs the cycle "from initial presentation, technical evaluation, negotiation, to closing and onboarding," and Fireworks' AE works with internal teams "to shape tailored solutions, POCs, and fine-tuning approaches" (both opened September 26, 2026).

Anthropic's guide to defining success criteria gives a good test for each criterion: it should be specific, measurable, achievable and relevant. It lists common criteria such as task fidelity, consistency, latency and price. Use those words with the buyer. They turn "does it work?" into a list both sides can check.

Write an evaluation plan of one or two pages that states:

• Scope. One workflow, not five.
• Test set. Which real examples, how many, who selects them, and who approves sharing them.
• Criteria. Three to five, each with a pass threshold agreed in advance.
• Judge. Who scores the outputs, and how disagreements get settled.
• Dates. Start, end and the decision meeting, with the economic buyer invited.
• Next step if it passes. The commercial terms and the first production use.

The last line matters most. An evaluation without a pre-agreed next step is a free consulting project. If the buyer will not commit to a decision meeting, treat the deal as unqualified. For more on building test sets and graders, see how to evaluate AI agent performance.

Output: an evaluation plan the buyer has approved in writing. Exit gate: that approval, plus a date for the decision.

Stage 4: Price on usage without surprising anyone

Many AI products are priced on consumption. Model providers publish per-token prices, as the OpenAI API pricing and Claude pricing pages show. Some application vendors price on outcomes instead. Sierra described outcome-based pricing on December 10, 2024 as pricing tied to results "such as a resolved support conversation." As of September 26, 2026, Intercom's pricing page lists its Fin agent at "$0.99 per outcome."

Whatever the model, the buyer needs a cost forecast they believe. Use the evaluation to build it.

1. Record usage per task during the evaluation: tokens, documents, conversations or resolutions, whichever unit you bill.
2. Multiply by the volume from Stage 2, and show a low, expected and high case.
3. State every assumption in writing, especially the share of tasks the product will handle without a human.
4. Offer whatever commitment structures your company sells, such as prepaid credits or a committed annual spend, and explain the tradeoff.

The buyer's finance team will ask what happens if usage doubles. Answer it before they ask. Agreeing on the forecast method is the exit gate, even if the final number is still under negotiation. The build-business-case skill shows how to model buyer value without inventing ROI, and the prepare-negotiation skill covers the commercial conversation.

Stage 5: Security and legal review, started early

AI adds questions to a standard security review. Expect some version of these:

• Training on customer data. Buyers will ask whether their data trains the vendor's models. Know your company's written answer and where it is published. Anthropic's privacy center, for example, says "By default, we will not use your inputs or outputs from our commercial products to train our models" (Anthropic Privacy Center, checked September 26, 2026).
• Subprocessors and model providers. If your product calls a third-party model, the buyer will want to know which one, where it runs, and how long data is retained.
• Controls frameworks. Security teams may send a questionnaire based on the Cloud Security Alliance's AI Controls Matrix, which CSA first released on July 10, 2025 and updated to version 1.1 in July 2026, alongside their usual SOC 2 and data processing requests.
• Output risk. Who is liable for a wrong answer, and what review steps the workflow includes.

Send the security package in the same week the evaluation plan is signed. Name an owner on your side for every open question. If a review will not finish before the target close date, move the date openly with the champion, rather than finding out on the last day of the quarter.

Output: security approval and agreed contract language. Exit gate: both.

Stage 6: Close on the date you agreed

If Stages 3 to 5 went well, the close is a meeting, not a negotiation marathon. Hold the decision meeting from the evaluation plan. Present results against the agreed criteria, including the ones that did not pass and what you propose to do about them. Then ask for the signature.

Use a mutual action plan to keep the last steps visible: procurement, legal signatures, purchase order and the first production milestone, each with an owner and a date. The create-mutual-action-plan skill describes a buyer-owned version.

If a criterion failed, say so. A buyer who discovers a hidden failure after signing becomes a churn risk and a bad reference.

Stage 7: Hand off to customer success or the FDE team

On a usage-priced product, the deal is not done at signature. Revenue arrives when the workload reaches production. Baseten's AE posting, opened September 26, 2026, describes the cycle as running "from first call to first production workload."

Write a handoff document that gives the delivery team:

• the workflow, the owner and the business reason from Stage 1
• the fit summary and blockers from Stage 2
• the evaluation plan, results and every promise made during the deal
• the usage forecast and its assumptions from Stage 4
• open security or legal commitments from Stage 5
• the names of the champion, the economic buyer and the person who judges quality

If your company uses forward deployed engineers, the FDE engagement playbook shows what they need from the deal to scope production work. The handoff-customer skill gives a checklist for the customer success version.

Stay on the account until the first production milestone. The next deal with this customer depends on it.

Where to go next

• Read what the AE role owns in the AI account executive career guide, and practice with the AE interview guide.
• See the buyer's side in what is different about selling AI.
• Understand how deals turn into pay in the guide to OTE and sales pay plans.
• If you build pipeline for AEs, the AI SDR outbound playbook covers the stage before discovery.