Enquiry to quotation
The main end-to-end process. Everything else in the product supports this.
The main end-to-end process. Everything else in the product supports this.
What this process achieves
A customer’s request for quotation — usually mail with attached datasheets — becomes a priced Flowtech quotation naming a specific product and order code for every instrument asked for, with the gaps and deviations visible before it is sent. When a purchase order arrives, it is compared with that quotation before an order is raised and handed to the ERP.
Who is involved
| Party | Part they play |
|---|---|
| Customer | Sends the enquiry, answers questions about missing parameters, later sends a PO |
| Flowtech colleague | Often forwards the customer’s enquiry into the sales mailbox |
| Sales person | Works the case, corrects what the reading got wrong, sets prices, sends the quotation |
| Office head | Assigns, approves the order, ERP handoff |
| The system | Syncs, reads, splits, extracts, recommends, drafts, compares |
What starts it
Mail landing in an enrolled Flowtech mailbox. Sync is continuous (Graph delta), not a button. See Collecting mail.
The steps
1. Collect the mail. System acts. It fetches new mail, saves attachments, joins each conversation, labels each message, judges whether it changes anything technical, recovers the origin behind a forward, and resolves the customer. Unknown senders become review items. The conversation appears in the inbox marked as needing processing.
2. Review the queue. Sales person acts. The inbox shows open work with its type, why it needs work, and whether a quotation already exists.
3. Read the documents. System acts. Attachments are converted to text — tables first so a bill of quantity keeps its structure, scanned pages through character recognition. Documents that cannot be converted are marked failed and the rest continue.
4. Identify the line items. System acts. One line per distinct instrument specification. Tags sharing one specification are grouped onto a single line. Each line gets a category — flowmeter, level meter, level switch, or not something Flowtech makes.
5. Extract the parameters. System acts. For each line, every parameter relevant to its category is recorded as stated, assumed, or missing. Known fluid properties are filled from the reference library. The list of missing required parameters is what goes back to the customer.
6. Recommend the products. System acts. The catalogue is scored. Each line gets a ranked shortlist, a fit band, the reasons behind every rejection and warning, a size check, and a compliance verdict.
7. Review what was read. Sales person acts. They see each line, every parameter with its origin and evidence, the flags, and the suggested products. Anything missing is chased with the customer — the reply lands on the same conversation and puts it back in the queue.
8. Draft the quotation. Sales person acts, system assists. Opening the quotation builds one line per quotable item: the chosen product, its option menus marked allowed, ruled out or unconfirmed, and the order code. Header fields come from the party master where known.
9. Price it. Sales person acts. Line discounts, overall discount, charges, tax treatment, payment and validity terms from the T&C master.
10. Send it. Sales person acts. FlowOS sends. Customers see the engineer; replies come back to the shared office mailbox. The send is recorded so it cannot be mistaken for an unquoted job.
11. Take the order. When a PO arrives. Lines are compared to the quotation. Mismatches are held. A confirmed order is a sales order; the office head hands it to the ERP.
12. Close the conversation. Sales person acts. Closing takes it off the open inbox. If the customer replies later with something that changes the requirement, it reopens by itself.
Decision points
| Point | What routes it | Consequence |
|---|---|---|
| Is this an enquiry at all? | The document type | A PO or finance message is still held, labelled so it can be filtered. Type does not drop it from processing — a revision on a quoted thread must not vanish |
| Does a reply need re-reading? | Whether it changes a number, material or model | If it changes nothing, the conversation is left alone |
| One instrument or several? | Whether the documents show several | Several forces a full split |
| Is this something we make? | The line’s category | A category we do not make produces no quotation line, with a reason |
| Can we quote the product asked for? | Whether a stated requirement breaches a known rating | Ruled out with the reason, alternative offered, requested product stays visible |
| Can any of our sizes read this duty? | Published sizing tables | A wrong bore is correctable; a duty no published size reaches rules the family out |
| Does the line send? | Whether every applicable option position is resolved | An incomplete order code stays on screen and is left off the document |
| Does the PO match? | Comparison on line keys | Mismatch is held; nothing raises an order on it |
Rules that apply
R1–R14, R16–R38, R40–R45, R53–R58 in the business rules register.
What happens if it stalls
| Situation | What the business sees |
|---|---|
| A document cannot be converted | That attachment is marked failed; the rest is processed. Failed is final unless retried by hand |
| The reading fails partway | The conversation shows as failed at the stage it stopped, and stays in the queue |
| No product fits | The line still appears with the reasons; the shortlist is not emptied |
| Nothing can be priced | Totals show as unpriced rather than as a zero |
| Send fails | The outbound row stays failed and can be retried. The draft is not lost |
| ERP is down | The handoff row stays in the queue |
Related: Preparing a quotation · Processing a case.