Back to blog Engineer or Procurement: Same Product, Different Prompt

Engineer or Procurement: Same Product, Different Prompt

The engineer asks about tolerances, the buyer asks about lead times, and the two questions retrieve different pages. Most industrial sites answer only one.

Two people at the same company will consult an assistant about the same purchase, days apart, and ask questions with almost nothing in common. The engineer wants to know whether the part survives a duty cycle. The buyer wants to know whether the supplier survives an audit. Both questions retrieve pages. They rarely retrieve the same page, and most manufacturer sites are written so that only one of the two has anything to find.

Two vocabularies, one product

The engineering question is about behaviour under conditions. It carries materials, tolerance classes, operating ranges, media compatibility, mounting constraints, failure modes, interfaces with other equipment. It often arrives as a scenario rather than a product name: something that handles this fluid at this temperature without this kind of corrosion. The answer the engineer wants is technical and specific, and they will discard a supplier who cannot supply it before anyone in purchasing hears the name.

The procurement question is about risk and supply. It carries certifications, country of manufacture, lead time, minimum order quantities, second sourcing, spare parts availability, warranty and support terms, financial and compliance standing. It also arrives phrased around a scenario: who can supply this component into this market, approved to this standard, without a single point of failure. The answer they want is commercial, and a technically perfect supplier who publishes nothing about availability or approvals is a supplier they cannot justify.

Notice that neither person typed your brand name. Both typed a need. This is the shift that catches manufacturers whose entire web presence assumes the visitor already knows who they are.

Why this splits at the retrieval layer

Retrieval matches a question against passages, so the vocabulary of the question decides which passages come back. A page dense with tolerance tables and material designations is a strong match for the engineer's phrasing and a weak match for the buyer's, even when both describe the same product. The procurement question tends to pull in pages that were never written by your engineering team at all: a distributor's stock page, a marketplace listing, a directory entry, a trade association member profile.

That asymmetry explains a result many exporters find puzzling. Ask an assistant a technical question about your category and your own site gets cited. Ask a sourcing question about the same category and your distributor, or a competitor with a better-organised catalogue, gets cited instead. Nothing changed about the product. The question changed, and with it the set of pages that could answer it.

Build the prompt set around who is asking

The practical move is to stop testing with one list of questions and start testing with two, written in the language each role actually uses.

  • Engineering prompts. Describe the application, not the product. Include the constraint that usually disqualifies suppliers: the temperature, the medium, the certification of the material, the space envelope. Ask which components or suppliers are suitable, and ask why.
  • Procurement prompts. Describe the sourcing situation. Approved suppliers for this component in this country, alternatives to a named incumbent, suppliers who can support a second source, what to verify before qualifying a new vendor in this category.
  • Ask both in every language you sell in. Roles are not distributed evenly across markets, and neither is the material available for a model to read. The procurement vocabulary in particular is highly local: the words for approved supplier lists, framework agreements and incoming inspection do not translate mechanically.
  • Record which pages get cited, per role. The gap you are looking for is not a missing brand mention. It is a role whose questions never reach any page of yours.

This is a different exercise from checking whether you are visible in each export market. That one varies the market and holds the question steady. This one holds the market steady and varies who is asking. Both matter, and a prompt set that mixes them without labelling them produces an average that hides both problems.

What to publish when the buyer side comes back empty

The usual finding is that engineering content exists in abundance and procurement content does not exist at all. Some of the gap can be closed without inventing anything, because the facts already sit in your ERP, your quality manual and your sales team's heads:

  • Where the product is manufactured, and where it is assembled if those differ.
  • Which approvals apply, to which product family, from which body.
  • How the product is supplied: order quantities, packaging, stocked versus made to order, typical availability stated honestly rather than optimistically.
  • Spare parts and support: what is kept available, for how long after a model is superseded.
  • Who to contact for a quotation in each market, and what information they need to quote.

None of this requires promising delivery dates you cannot hold. A page that says a range is stocked in Europe and typically ships within a stated window, or that a product is built to order after technical clarification, gives both a buyer and a retrieval system something concrete. Silence gives neither.

The limit of the exercise

Splitting your prompt set by role tells you where the holes are. It does not tell you that filling them will produce mentions, and no honest tool will tell you that either. What can be observed is the state of the answers and how it moves: which roles' questions surface you, which surface a reseller, which surface nobody in your category at all.

PSentry generates prompt sets per site and runs them across ChatGPT, Claude, Gemini and Perplexity in each language you sell in, on a scheduled cadence, and reports who is named and which sources were used. It is a measurement instrument. It does not write the missing procurement pages, and it does not influence what any assistant answers.

Frequently Asked Questions

Which role should we prioritise if we can only fix one?

Look at where your quotations actually die. If enquiries arrive technically qualified and stall on availability and approvals, the procurement side is the gap. If you rarely get enquiries at all for applications you can serve, the engineering side is not being reached.

Should we build separate pages for engineers and buyers?

Separate sections on the product page are usually enough, as long as each section states the product designation inside its own text. Retrieval pulls passages, so a commercial section that never repeats the product name is hard to attach back to the product.

Our lead times change constantly. Should we publish them at all?

Publish the shape rather than a promise: stocked or made to order, the range of typical availability, what shortens or lengthens it. That is more useful than silence and more defensible than a number you would have to keep correcting.

Does this differ between markets?

Considerably, especially on the procurement side, where approved-supplier processes and documentation expectations are local. Running the same role prompts in each language you sell in is the only way to see it, and the differences are often larger than the differences between roles.

What if our technical documentation sits behind a login?

Then it is unavailable to retrieval, and effectively unavailable to the engineer doing early research. Keeping detailed drawings gated is reasonable. Keeping the basic operating envelope and material designations gated is what removes you from the conversation before it starts.