پیش از قیمت‌دادن، استعلام را به پرونده نیاز تبدیل کنید

A large share of market inquiries begins with a short sentence: “Do you have this item?” or “Give me a price for this job.” The issue is not that the buyer is brief. The problem begins when that short sentence turns directly into a price, an inventory promise, or a delivery commitment. In between, each person fills the blanks with their own interpretation, and those interpretations later become disputes.

In this market I have seen that good sales comes from building a steady routine, not from relying on one person’s memory and instinct. An experienced salesperson may infer a buyer’s intent through a few short questions, but a business that depends on one person’s inference loses decision quality when people change, the market gets busy, or delivery pressure rises.

The answer is not to burden sales with useless forms. The answer is to turn every important inquiry into a “requirement file” before it becomes an offer: a short but complete file that shows exactly what the buyer needs, what the need is for, what cannot change, and which parts are still unclear.

The requirement file must be understandable to every function. Sales needs to know what it can discuss and what it must not promise. Sourcing needs to know which options to pursue. Quality control needs to know which document or test is required. Delivery needs to know the real packaging, loading, destination, and timing constraints. If each function has to start asking from scratch again, the file has not done its job yet.

The starting point of the file is not the product name; it is the end use. A grade, thickness, or size may be requested for different applications, but the sensitivities of those applications are not the same. The salesperson should know which product, component, structure, production line, or subsequent operation will use the material. The buyer does not need to reveal business secrets, but they should explain enough to prevent material selection based only on a market label.

After the application, technical specifications must be recorded in a verifiable language. Material or grade, dimensions, thickness, width, length, supply form, surface condition, referenced standard, and essential properties belong here. If the buyer uses common market names, record those names, but also note whether the technical equivalent or acceptance condition still needs confirmation. A common name alone is not a technical specification.

Tolerances should not be hidden under a broad label such as “good quality.” Thickness, width, length, camber, flatness, coil weight, or any other sensitive feature should be asked and recorded separately. If the buyer does not know the precise tolerance, that uncertainty must also be explicitly recorded; the sales team should not guess on the buyer’s behalf. “Tolerance is not important to the buyer” and “tolerance has not yet been defined” are very different situations in purchasing and sourcing.

Required volume and consumption plan are the next parts of the file. The quantity needed immediately and the quantity needed over a period are different subjects. It should be clear whether the buyer seeks a trial purchase, inventory replenishment, project supply, or a recurring consumption plan. The file should also state whether the stated volume is firm, an early estimate, or subject to the buyer’s internal approval. This distinction prevents incorrect reservation, rushed purchasing, and unsupported promises.

The buyer’s downstream operations also affect selection. Cutting, bending, welding, punching, drawing, painting, plating, or any other process may change the suitable quality or supply form. The salesperson does not need to act as the buyer’s engineer, but they should know whether the material will undergo an operation that depends on a specific property. This simple question can sometimes prevent proposing a material that appears similar but is unsuitable.

Treat quality documentation separately from the material itself. Some buyers only want the product, while others require a chemical analysis sheet, certificate, approval, test report, heat traceability, or other defined documents. The file should make clear which document is mandatory, who will accept it, and whether it must be reviewed before shipment. Saying “the documents are available too” is not enough; the document type and the time of delivery must be specified.

Transportation and delivery are also part of the requirement, not an issue to consider after the sales agreement. Unloading location, route restrictions, vehicle type, loading capability, packaging, surface-protection needs, the buyer’s receiving capacity, and delivery conditions should appear in the file. A material may be suitable in price and quality but impractical because of transport limitations or unloading conditions. Good sales sells material that can actually be delivered.

Do not reduce the required timing to one vague date. It should be clear which stage the buyer needs the material for, on what date it is needed, what delay would affect, and whether phased delivery is acceptable. “As soon as possible” and “before the line stops” are meaningfully different. The requirement file should turn urgency into a verifiable condition, not a verbal pressure on the team.

Another important section is the risk of nonconformity. If the wrong material arrives, what happens? Is replacement all that is needed, or will the buyer’s operation stop, a component be rejected, or required documentation remain incomplete? There is no need to create frightening scenarios for the buyer. The point is simply to understand the impact of an error so that the level of review, the approval method, and the commitment boundary match the risk.

To keep the file from becoming a personal notebook, each section needs a defined approval owner. Sales collects and records the initial information, while the buyer confirms the application and priorities. Sourcing confirms availability and possible alternatives. Quality control reviews acceptance of specifications and documents. Delivery assesses whether the logistical commitment can be executed. A shared file does not spread responsibility vaguely; it makes the location of responsibility clear.

The practical rule is this: while sensitive parts of the file remain incomplete, the team may discuss options, ranges, assumptions, and the review path, but not make a firm commitment. For example, if tolerance or quality documentation has not been defined, the price may be conditional, but statements such as “this is exactly right for your use” or “it will definitely arrive on your required date” should not be made. The commitment boundary should be visible in the file itself, not only in the salesperson’s mind.

The signs of an incomplete need are usually visible. The buyer states only the market name of the material but does not explain the application. They state a volume but have no withdrawal plan. They ask for delivery timing but the destination and unloading capacity are unclear. They request an analysis sheet but do not know which property matters. Or several people on the buyer’s side give different answers. These are not reasons to reject the inquiry; they are signals that the file is not ready for a firm offer.

In that situation, the salesperson should not tire the buyer with a questionnaire. Questions should be asked in risk order. First identify where a wrong material choice could cause the greatest damage: application, specification, timing, documentation, or delivery. Then ask only the questions needed to close that uncertainty. If the requirement is complex, the file can be completed through several exchanges, but every exchange should show what has been clarified and what remains open.

Consider a fully hypothetical example: a buyer sends only thickness and quantity for sheet material and asks for a price. The requirement file shows that surface specification, tolerance, downstream operation, and the real consumption date are still unknown. At this stage, the right response can include several conditional options and a request for additional information, rather than a firm price that later faces a nonconformity claim, a changed request, or a delivery problem.

Start this method with a short form, not a complex system. The form can be digital or paper-based, provided everyone can access the single version and changes are recorded. At the end of every conversation, the salesperson should summarize the file for the buyer in clear language: what we understand, what has not yet been confirmed, and who owns the next step. This creates shared understanding before the transaction.

Once requirement files accumulate, they are more than a sales tool; they become a source of business learning. The team can see which questions create the most rework, which types of requests are usually incomplete, and where promises exceed operational capability. The principle is simple: a good purchase does not begin with bargaining. It begins by turning a vague request into a need that can be assessed, approved, and delivered responsibly.