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 issued. When a purchase order arrives, it is compared with that quotation before an order is raised and handed to the ERP.

Who is involved

What starts it

Mail landing in an enrolled Flowtech mailbox. Sync is continuous (Graph delta), not a button. See Collecting mail.

Or a salesperson entering an enquiry that came by phone, WhatsApp, a visit or a marketplace, with ＋ New enquiry in the inbox. They type their notes or paste the chat, attach any files, and choose the customer: one from the Party Master, or a new customer kept on the enquiry only. FlowOS reads it as it reads an email, so the steps below apply to it from the reading on, with these differences: the customer is the one the salesperson chose, not one the reading finds; the person entering owns the enquiry; and a reply to the contact goes out as a new email, or is not offered when the contact gave no email. See Entering an enquiry by hand.

When the lines are already known, Build lines myself enters the enquiry with no reading: the salesperson adds each line with ＋ Add line, and Generate quotation waits until one exists. ＋ Add line also adds a line the reading missed on any enquiry. See Adding a line. Once a quotation is issued, the lines it covers lock until a revision is started.

The steps

1. Collect the mail. System acts. It fetches new mail, saves attachments, joins each conversation, types each message, recovers the origin behind a forward and, for mail after a quotation, links it to the enquiry and quotation it answers. A client email that arrives again and adds nothing is linked to the first and not read again. An enquiry appears in the inbox once its requirements are gathered.

2. Name what is asked for. System acts. For an enquiry, FlowOS names which product categories of the item group master the client asks for — flow meters, rotameters, level indicators, level switches, level transmitters, pressure transmitters, sight glasses — from the subject, the attachment names, what the client wrote and a short excerpt of each converted attachment. One enquiry can ask for several, and for each it notes the likely product type, such as a glass tube or a metal tube rotameter. A forward is read as the client’s email, whether it sits below the forward or is quoted below a colleague’s reply; the colleague who passed it on is recorded, and their note is not read as a requirement. When no client can be found behind it, as when a colleague restates a client’s request, the whole email, the colleague’s words included, is read as the request, and no one is recorded as passing it on. When no category is confirmed, the email is not linked as an enquiry: it joins the enquiry its conversation already holds as a follow-up, or waits in Needs Review, and no lines are gathered from it. It also notes what the client asks of the offer — delivery, price basis, payment, taxes, validity and warranty, documents to send, inspection, a make or model, or any other instruction about the offer — and when the offer is due, from the client’s own words. Attachments whose names mark them as the client’s terms are listed, not read. It records who the client is — name, designation, company, email, phones, GSTIN and address — from their signature, not from the colleague who forwarded it; with no client found, no contact is read.

3. Review the queue. Sales person acts. The inbox shows each enquiry as a card on a board, under New, To review or Ready to quote (and, once a quotation is issued, Quoted, Revision requested or Ordered), with its client, what was asked, how many lines are still to review and when it is due. Other mail is listed beside the board with its type (Inbox).

4. Read the documents. System acts. Attachments are converted to text — tables first so a bill of quantity keeps its structure, and attached pictures and scanned PDFs through the picture reader once the email is typed as an enquiry, a scanned PDF only when every mailbox the email was delivered to is one requirement gathering covers. Documents that cannot be read are listed as not read and the rest continue.

5. Identify the line items. System acts. One line per distinct instrument specification. Tags sharing one specification are grouped onto a single line. Lines are read for each category named in step 2 that holds a requested item; each line takes that category, or is marked as something Flowtech does not make. A line that starts with a product on Flowtech’s outside-range list is excluded automatically with its reason (R92), and so is a line whose remark says the client deleted it, put it on hold or has it supplied by others, with the client’s words as its reason (R112); a person can reopen either.

6. Extract the parameters. System acts. For each line, every parameter relevant to its category is stated, inferred, 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.

7. Recommend the products. System acts. Each line’s families are checked against what the line states: the named family first, else the line’s own category. The ones that fit are ranked and the ones ruled out keep their reasons. Computed for each line and shown on the line list and in the line’s panel as a suggestion, not a confirmation.

8. 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, from Raise query on the enquiry (Inbox) — the reply lands on the same conversation and puts it back in the queue.

9. Generate the quotation. Sales person acts, system assists. The Quotation card beside the enquiry generates a numbered draft with one line per instrument from line review. Each line says what stops it being issued. An option still open is chosen on the line and saved on the enquiry. Header fields come from the enquiry’s contact where known.

10. Price it. Sales person acts. Rates, line discounts, overall discount, charges, and payment, delivery and warranty terms from the terms template. Tax is worked per line from its HSN.

11. Issue it. Sales person acts. Issuing needs a place of supply and a company state on the list of states, and is refused while a change typed on the quotation is withheld (R36) or when its grand total changed after the page was opened. It freezes the version and its PDF can be downloaded and sent from the salesperson’s own mail. FlowOS does not send it yet. A later change request is answered by revising it.

12. Take the order. When a PO arrives. FlowOS reads it and compares its lines to the quotation. Mismatches are held; see Checking a purchase order. A confirmed order is a sales order; the office head hands it to the ERP.

13. Follow it up on the board. FlowOS acts. The enquiry’s card moves to Quoted once the quotation is issued, to Revision requested while the client asks for a change, and to Ordered at the client’s first sign of an order. Closing a conversation is not built yet: nothing takes an enquiry off the board as won, lost or regret. See Lifecycles.

Decision points

Rules that apply

R1–R14, R16–R38, R40–R45, R53–R58, R64–R79, R81–R86, R88 in the business rules register.

What happens if it stalls

Related: Preparing a quotation · Processing a case.