In enterprise solution selling, discovery should establish the business problem, sites and users affected, decision process, technical constraints, budget owner and cost of delay before a proposal is written.
A customer says they need a faster connection. The easy response is a faster connection quote. It may even be the right answer. But first I want to know what broke, who noticed and what happens if it breaks again.
In telecom enterprise sales, the same headline request can point to very different work: a branch rollout, an application with poor uptime, a backup link or a service team that cannot reach customers. Product knowledge matters. Diagnosis comes first.
Follow the problem through the business
Ask which people or processes are affected and what the current workaround costs. Then map the locations, applications and service expectations. A technical requirement without the operating context can lead to a precise proposal for the wrong job.
The buying group is another part of discovery. The person feeling the pain, the person evaluating the solution and the person approving spend may be three different people. If you hear only one voice, mark that as an open question.
Put constraints on the table early
Installation conditions, existing contracts, security requirements and timelines can change the design. I would rather expose a constraint before pricing than apologise for it after an order. Bring a technical colleague into the conversation when the answer needs one.
Then repeat the problem back in plain language. If the customer does not recognise their own situation in your summary, keep asking.
Proposal comes after agreement on the problem
A good proposal makes the link between requirement, solution, delivery and commercial terms easy to inspect. It also says what is excluded. That clarity may slow the first document by a day and save weeks of confusion later.
The test is simple: could the customer explain to a colleague why this option was chosen? If not, the selling work is unfinished.
