The discovery call template most enterprise AEs use is a list of questions. Budget, authority, need, timeline. Current state, desired state, gap analysis. Pain points, priorities, decision criteria. The questions are reasonable and the answers are useful. The problem is that the customer can see what you are doing and it does not build the kind of trust that moves a complex deal forward.
An interview extracts information from a subject. A diagnostic is a collaborative process of understanding a situation that neither party could have articulated fully before the conversation started. The distinction matters because enterprise technology decisions are rarely made in response to questions the vendor thought to ask. They are made in response to problems the customer was not quite able to name until someone helped them name it.
What an interview sounds like
The interview discovery call has a recognizable shape. The AE opens with a few rapport questions, transitions to the formal discovery, works through a mental checklist of qualification criteria, and closes by summarizing what they heard and suggesting a next step.
The customer answers the questions they are asked. They describe the problem as they currently understand it. They share the information they are comfortable sharing. And they leave the call with approximately the same understanding of their situation that they arrived with, minus the time they spent on the call.
This is not useless. The AE learns things. The qualification criteria get filled in. But the customer learns nothing new about their own situation, and learning nothing new from a vendor conversation is the beginning of treating that vendor as a commodity. A conversation that does not change how the customer thinks about their problem is a conversation that will not be remembered.
What a diagnostic looks like
The diagnostic call starts from a different premise: the customer’s current understanding of their problem is incomplete, and the job of the first call is to help them understand it better.
This requires preparation that is different from the typical discovery prep. Instead of preparing a list of questions about the customer’s situation, you prepare a set of hypotheses about what the real problem is likely to be, based on what you know about the customer’s industry, their organizational type, their technology stack, and the problems you have seen in analogous situations.
You bring those hypotheses into the call not as conclusions, but as ways to structure a conversation. You share what you typically see in situations like theirs. You describe the problem patterns you have observed. You ask the customer to tell you where their situation diverges from the pattern or confirms it.
When the customer says something unexpected, you follow it rather than returning to your list. The unexpected things are usually the real signal: the piece of the situation that does not fit the standard pattern and that will shape the solution in ways neither party has anticipated yet.
The difference the customer experiences
The customer who has been through a discovery interview and the customer who has been through a diagnostic emerge from the call in different states.
The interview customer can describe what the AE asked and what they answered. They may have a follow-up meeting scheduled. They are evaluating whether the vendor seems competent and whether the product seems relevant. The relationship is professional and transactional.
The diagnostic customer can describe what they learned about their own situation. They understand something they did not understand before the call. The AE named a problem pattern they recognized, asked a question that made them think, or offered a frame that helped them articulate something they had been struggling to articulate to their own leadership. The relationship is different: the vendor is now associated with insight rather than just with a product.
In enterprise deals, the vendor associated with insight gets invited to conversations the vendor associated with a product does not. The AE who helped a CTO think more clearly about a problem is the AE that CTO calls when a different problem surfaces, before it becomes a formal RFP.
What this requires
Running discovery as a diagnostic requires knowing enough about the customer’s situation before the call to have hypotheses worth testing. That means research: the annual report, the recent press, the LinkedIn profiles of the technical leaders, the public engineering blog if there is one. Enough to arrive with a specific and informed point of view about what is probably true.
It also requires comfort with silence and with divergence. An interview covers all the questions on the list. A diagnostic follows the most interesting signal, even if it means leaving other questions unasked. An AE who needs to tick every qualification box in a single conversation cannot run a diagnostic, because the diagnostic requires using conversational space for exploration rather than information extraction.
The qualification criteria still matter. But in a diagnostic call, you gather qualification information as a byproduct of the diagnostic conversation rather than as the explicit purpose of the call. The customer reveals their budget constraint when they explain what they tried before. They reveal their decision process when they describe who else is going to need to understand the recommendation. The information you need is there; you just find it differently.
The longer arc
The goal of the first call is not to qualify the opportunity. It is to earn the right to a second conversation.
A customer who learned something from the first call will take a second call. A customer who answered questions for forty-five minutes and confirmed that yes, they do have a technology challenge in the area the vendor covers, will take a second call if they are not yet talking to competing vendors and if the calendar works. That is a weak reason to continue.
The AE running a diagnostic earns a specific reason to continue: they helped the customer see their situation more clearly, and the customer wants to know what the AE sees in the next layer of the problem.
That reason compounds. The second call that follows a diagnostic first call is also a diagnostic. By the third or fourth conversation, the AE understands the customer’s situation in more depth than any other vendor the customer is talking to, because the other vendors have been running interviews while this one has been running a collaborative investigation. The relationship has been building on something real, and the customer knows it.
The deals that close from this kind of foundation close differently than the deals that close from a qualification-driven pipeline. The commercial negotiation is easier because the trust is already there. The implementation goes better because the problem was understood more deeply. The renewal is less likely to be contested because the relationship was built on insight rather than on the initial sale.
None of this is possible in the interview model. The interview model produces pipeline. The diagnostic model produces the foundation for a relationship. In enterprise technology, the distinction determines what the account looks like in year three.