---
title: Enquiry to quotation
description: The main end-to-end process. Everything else in the product supports this.
sidebar:
  label: Enquiry to quote
  order: 1
---

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 |

```mermaid
flowchart TD
  mail["Mail lands in an enrolled mailbox"] --> join["Join conversation / recover origin"]
  join --> docs["Read attachments"]
  docs --> lines["Split line items"]
  lines --> params["Extract parameters<br/>stated / assumed / missing"]
  params --> suggest["Suggest products"]
  suggest --> quote["Draft and send quotation"]
  quote --> po["PO arrives → compare"]
  po --> so["Sales order"]
  so --> erp["ERP handoff"]
```

## What starts it

Mail landing in an enrolled Flowtech mailbox. Sync is continuous (Graph delta),
not a button. See [Collecting mail](/business/workflows/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](/business/business-rules).

## 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](/business/workflows/preparing-a-quotation) ·
[Processing a case](/business/workflows/processing-a-case).