Use the sales call to establish what you can actually deliver
Clarify the workflow, access constraints and decision owners before making a delivery commitment. Separate evidence from assumptions, explain feasible alternatives and record the next test with its owner and date.
20 MIN
TL;DR: Use technical discovery to establish what you can deliver and what still needs evidence. Make commitments specific enough that the customer and your own team can distinguish a supported capability from an untested assumption.
Where you are. First lesson of the flagship course. Foundations began after a project existed. This course begins before the commitment, when customer goals and delivery constraints still need to be reconciled.
Why you are in the room
The account executive needs a technically credible delivery plan. The customer needs to understand whether the proposed workflow can run in their environment. Your job is to connect those questions with evidence: which system holds the data, what access exists, and which person will use the result.
Sales and engineering both depend on accurate commitments. Do not cast your colleague as the person who sells and yourself as the only person allowed to tell the truth. Agree before the call who answers commercial questions, who owns technical follow-ups and which claims have actually been demonstrated. If a request exceeds the tested capability, say that while there is still time to change the plan.
The pressure can be subtle. A customer asks whether an integration is supported; you know the product has a connector with the right name. The unanswered questions are its version, access mode, required fields and write permissions. “Supported” may be heard as “ready in our tenant next Monday.” Explain the boundary before that interpretation becomes the schedule.
A quarter-end deadline can make clarification harder, but the date does not tell you whether the participants are acting in good faith. Ask what must be decided today and which checks can happen before a delivery commitment. An internal signing target is not evidence that the customer's data is ready.
Three questions that produce useful follow-ups
Where does that data live today? Ask the customer to walk one real case through its systems. The transport system might hold shipment status, while the latest exception is in a portal and the contract sits in a document store. For each hop, identify the owner, interface and freshness. Counting systems is not a schedule; testing access and identifying approval dependencies gives you something you can schedule.
Has anyone here said no to something like this before? Ask what was proposed, which control or constraint caused the decision, and whether the constraint still applies. A prior rejection may concern a different data class or deployment pattern. Request the decision record rather than treating a pause, a recollection or a job title as approval or refusal.
If this works, whose work changes? Find the person who will use the output and who can change the workflow. If nobody in this meeting knows, record an unresolved ownership question and arrange the missing conversation. It does not prove that an owner does not exist elsewhere in the organization.
These questions should produce artifacts: a sample export, an access request, a workflow observation or a decision record. A call full of confident answers can still leave all four missing.
Explain the feasible option and its conditions
Separate a capability limit from a resource tradeoff. A feature might be available with a different deployment topology, additional integration work or a later date. Another request might violate a firm security restriction or require information that the source never records. Do not convert every refusal into a price; some constraints rule out the requested mechanism.
Use this shape: what is supported, what remains to be verified, what the next check costs, and who chooses the scope after that check. For a customer-hosted deployment, a truthful answer might be: “We support that topology. We have not checked your egress and identity requirements. We can review those with your platform owner this week, then confirm the deployment estimate.” This is an example response, not a promise about every customer's review process.
If the customer supplies a previous six-week security review, treat it as planning evidence. Confirm whether the same reviewers, data and topology apply. It does not prove that the next review takes six weeks, and it does not decide on its own whether the pilot should move to phase two.
When a mechanism is prohibited, state the reason and offer an alternative only if it satisfies the requirement. Do not offer an external service as the easy route around a no-external-processing rule. An on-premises alternative may be feasible; if it is not, declining this scope can be the correct delivery decision.
Work a discovery call from supplied notes
The following synthetic notes introduce the freight exception workflow developed later in this module. They are statements from a fictional meeting, not verified capabilities.
| Speaker | Statement | What you still need |
|---|---|---|
| Buyer | We need exceptions handled within fifteen minutes | Start and end events; whether “handled” means identified, reviewed or resolved |
| Platform owner | You can have a daily export; API access is not approved | Export fields and arrival time; named API reviewer and decision date |
| Operator lead | Shipment lookup is slow; refunds still need my approval | One observed case and the approval boundary |
| Account executive | We can demonstrate the assistant in two weeks | Whether the demo uses synthetic records or customer data, and what it proves |
A daily export can support a historical demonstration. It cannot establish that newly created records will be available within fifteen minutes. Refund approval also does not disappear because identification becomes faster. Keep the proposed first workflow at lookup and evidence presentation until the owners agree otherwise.
A useful response to the room is: “We can demonstrate lookup with the supplied export, subject to checking its identifiers. That would test matching on historical records. The fifteen-minute live workflow needs a separately approved data path and a defined operator step.” The response offers a concrete next action while keeping the two claims distinct.
Notice the question still missing: when a record is absent, should the assistant say it cannot match, or might it present an old shipment with a similar identifier? Ask that before treating a convincing demo as a valid lookup flow. A correct refusal can be more useful than a fast wrong match.
Write a commitment record the same day
Record the requested behavior, supporting evidence, unresolved assumptions and the exact commitment made. Give each follow-up an owner and date; send the relevant scope and dependency statements back to the customer for correction. An internal note helps your team but does not prove the customer accepted its interpretation.
For the synthetic call, the record should say that the two-week milestone is a demonstration on a defined dataset, not a promise of live integration or automatic refunds. The platform owner supplies the export schema and the operator lead reviews the proposed end event. If API approval slips, the demonstration can still answer a matching question, but its results cannot be described as a production latency test.
The spine below runs the call end to end, and marks what each of the three questions is supposed to leave behind.
Do this before moving on
Using the supplied notes, write a four-line follow-up: proposed demonstration, excluded actions, two open dependencies and the next decision. Then change the buyer's requirement to “every newly created exception must be handled within fifteen minutes, including weekends.” Decide what evidence the daily export can support and what would have to change.
Worked review. Keep the demonstration scoped to historical lookup. Ask for a live data path with a measured freshness guarantee and an operator coverage plan before committing to the new requirement. A daily export and weekday-only approval process do not meet it. If those dependencies cannot change, narrow or decline that live scope; do not relabel the historical demo as a successful test of it.
Go deeper
- Requirements discovery is the technique underneath the three questions, in more depth.
- Explaining trade-offs is how a no becomes a price the customer can decide on.
- Stakeholder management covers the gatekeeper you just found and what to do with them.
- Four people decide your deployment is the Foundations lesson this one assumes.
- Saying no without losing the room takes this move deeper, mid-engagement rather than pre-sales.
- Why customer-facing engineering? is worth answering again now that you have seen the pre-sales half.
Key takeaways
- Establish capability boundaries with sales colleagues before the customer turns a discussion into a date.
- Discovery questions should produce evidence, an owner and a next check.
- Missing information in a meeting is an unresolved question, not proof of missing ownership or approval.
- Separate a historical demonstration from live freshness and action commitments.
- Record commitments and exclusions with the customer while they can still correct your interpretation.
Check yourself
Answer before you look. Recalling it is what makes it stick; recognising it does not.
1A daily export is available, but API access is not approved. What can a two-week demo establish?
2Nobody on the call can name the adoption owner. What follows?
3Why is a connector's name insufficient evidence for a delivery commitment?
Sign in to track which lessons you have finished.