The inquiry arrives as an email or a CSV

Every house has a system in which orders come into being. Some have several, and the spare-parts case runs through whichever happens to be open. A direct link from outside into that system sounds orderly. It is a project: fields, permissions, errors that write at night, a test nobody runs after go-live. For a first inquiry path, that project is too large, and it does not solve the problem before it. That problem is the line that is not yet a line.

An email with clear details, or a CSV file with one line per position, can be opened. A person reads it and creates the case where your cases live. That person sees when the series does not exist or the quantity is implausible. An interface sees that only if you have taught it the check. Teaching it the check is the project all over again.

What should be in the file

Series, assembly, position, part number, designation, quantity. Add a note when the part number is superseded, and the address the quotation should go to. That is a small table, small on purpose. Every further column is a guess about your system. Guesses age badly. The small table ages less, because it describes the inquiry and not your screen.

The email may carry the same table in the text, for whoever does not want to read a file. Both carry the same content. What is not in the table is not hidden in the wording either. The customer set the quantity. You do not take it from the bill of materials because the column would otherwise be empty. An empty quantity is an incomplete inquiry and should not arrive at all.

Encoding and separators are dull, and they decide whether the file helps. A file that mixes comma and semicolon, or destroys umlauts, is no relief. Fix a format and keep it. The person taking the file over should not have to guess which column is the quantity.

What the file does not do

It does not post. It does not reserve. It does not write a price. It does not create a customer who does not yet exist in your records. All of that stays in the system built for it, and with the people who run that system. The file saves retyping from a story. It does not save the decision.

Anyone who hopes the CSV is already the interface, and that the next step is only "import it automatically", should still plan that step as its own project. Importing means duplicates, master data, number ranges named differently in your house than on the drawing, and an error log someone reads. That work is legitimate. It does not belong in the same week as the first released assembly.

The customer barely notices the file

The customer taps the drawing. An email or a file arriving with you is your process, not theirs. They need not know a format, or what your ERP calls the position. That ignorance is fine. It is why you translate once, on your side, into a fixed table, instead of again in someone's head at every inquiry.

If the table arrives and someone can take it over in five minutes, the path is usable. If it arrives and nobody knows which field is meant, the format has failed, however modern it sounds. Judge the path by that, not by the absence of an interface. The absence is a decision. The usable line is the result.

One line, one part

Several positions are several lines, not one sentence with commas. The customer may ask, in one case, for the knife, the facing, and the seal. In the file those are three lines, with the same series and assembly, or with different assemblies if they walked the machine. Each line carries its own quantity. The bill-of-materials quantity is not a column you quietly fill in. If the list says "4" and the customer wants "1", the inquiry is "1".

The note on a superseded number belongs in the same line, not in a second file and not in the subject. "Superseded by" plus the new number is enough. Inside sales then sees both keys and decides, in the quotation, which one to charge. A file that has already replaced the old number with the new one, without the sentence, takes that decision away. The clerk sees only the new number and does not know what the customer read on the sheet.

The address for the quotation is one line for the whole case, not a fresh one for every part. Name, company, email, and, if they want to pass one along, the customer's own order number. That number is not yet an order to you. It is a mark under which they find your quotation again. Do not confuse it with an order the file would have created. Nothing is created until a person creates it in your system.

What the person checks while taking it over

They check whether the series exists in your records. One digit too many, and the line belongs in a follow-up, not in the quotation. They check that position and part number belong together on this sheet. The file claims they do, because the customer tapped this drawing. A silent overwrite of the sheet after sending can make that claim stale. The revision the inquiry saw therefore stays traceable, even if you withdraw the sheet later.

They check the quantity for plausibility, not for obedience to the bill of materials. Fifty knives for one station can be right, if the customer is stocking up, or they can be a typing error. In doubt, ask briefly about the quantity, not about which part it is. The line should already have settled the identity. If it has not, the format or the drawing has failed, and the question is the old description again.

They do not check a price in the file, because none is there. The price comes into being with them. That is awkward for anyone who wants a dark run overnight, and it is why the first version arrives in a mailbox by day. Someone sees it. Someone can leave it if the series is wrong, instead of creating an order nobody placed by morning.

The mailbox is a process, not a stopgap

Decide who reads the email, and what happens to the file when that person is away. A shared mailbox beats the personal address of a clerk on leave. The file changes nothing about that. An unread mailbox is the same standstill as a note on a desk, only without the note a colleague sees in passing.

Keep the file with the case. Not as a backup ritual, but because the customer calls two weeks later and says "the inquiry from Tuesday". The line in your system and the file they sent should mean the same thing. If they no longer do, because someone bent a column, both sides go searching. Fixed columns are dull. Dull is the aim here.

An interface into your ERP can carry the same content later. The same columns, the same checks, a log someone reads when a line is rejected. The difference is the trigger, not a lack of care. While the columns do not sit, an interface automates the confusion. Once they sit, the import is its own project with its own test. One after the other. Not both on the day the first assembly is released.