By the Onsites AI team · Last updated · 5-minute read
Most small businesses run support and billing in two windows, and the seam between them is where money leaks: prices retyped from chat into an invoice tool, a discount agreed on WhatsApp and lost by Friday, an order confirmed in email that finance never quite matches to the quote. Onsites Mail closes the seam by design: quotes, orders, invoices and contracts come from one editor with one shared product catalog, sitting in the same workspace as the conversations they arise from — so the thread where a deal was born becomes the document it lives in, with a status trail support, sales and finance all read the same way. This guide walks the flow once, end to end: from "can you quote that" to "paid, thank you."
Every conversation in the desk auto-links to the customer record — the CRM setup guide covers the anatomy (accounts, contacts, opportunities) — which means the commerce flow starts with identification already done. The buyer who writes "quoting 400 units, 20ft container, to Hamburg" is the account whose history, past orders, and last agreed price sit in the same screen; when the quote is drafted, it inherits the names, not a memory contest. For brand-new buyers the linkage creates the record as the conversation goes — contact from thread, account from contact, the contacts guide's mechanic — so no one ever retypes an address a customer already typed. This plumbing-first step is what makes the rest of the guide unremarkable: the deal's data was assembled by the support process itself, at conversation speed.
Quotes are drafted in Onsites Mail — same editor family, same product catalog — and the practical difference from a template or a spreadsheet is that every line item is a catalog item: priced as the business actually prices it, with no re-typed amounts to go subtly stale. The discipline that makes quotes professional is small and consistent: name the buyer's terms in their words ("20ft, port-to-door"), state validity explicitly (dates, not "current pricing"), and use the quote-writing anatomy for the sentence structure. Send it from the thread — the quote leaves as your mail, into the conversation history where the request already lives — and its status flips to sent on the same trail finance will later read. The RFQ-to-proforma guide covers the heavier trade variant; the mechanics here are identical, only the line items differ.
Every document in this flow contains exactly one sentence that matters more than the rest — the money sentence: amount, method, timing, confirmation to expect. Written once, it reads "Invoice #1041, €12,400, payable by bank transfer within 14 days; you will receive a confirmation when it lands." Written badly it reads "as discussed" — and every follow-up, dispute and month-end email after that re-litigates what "discussed" meant. The anatomy (the refund guide and the overdue playbook both use it): one element per clause, numbers exact, dates exact, no hedging, no marketing warmth — money sentences are read carefully and forwarded internally on the buyer's side. Teams that standardize the money sentence across quotes, orders and invoices stop explaining "which amount in which currency by when" three times per deal, because the document family already said it once.
The document's status trail is the desk's financial story, and it is designed so that each acceptance is a transition rather than a re-creation: a quote accepted becomes the order (same lineage, same line items, no re-typing and therefore no quiet price drift); an order fulfilled — shipped, delivered per the order-tracking pattern — graduates into an invoice with the same shared identity. Invoices are sent from the same editor, and their statuses are the ones every finance conversation is really about: sent, seen, paid, and the one that earns its own guide (overdue, and what to do about it). Because support watched the deal be born, the invoice inherits context nobody retyped: who agreed what, when, on which channel. Small teams feel this most at month-end — the invoice trail is exactly as long as the conversation trail, and neither was assembled by hand.
Name them once and the one-window design stops sounding like a convenience. The divergent copy: quote at €12,400, invoice at €12,800 — re-typing between tools, the classic margin leak that also destroys trust when the buyer catches it. The lost concession: "20% off the reorder" agreed in a WhatsApp thread, absent from the quote because the thread lived in someone's pocket — the shared inbox fixes the capture, the shared catalog fixes the application. The orphan order: acceptance confirmed in email, no document trail, "did we ship it?" answered by memory instead of the status trail. The stale price: an old spreadsheet template carrying last year's numbers into this quarter's quote — one catalog updates in one place. Every one of these is a story about the seam between conversation and document; every one disappears when the documents are born where the conversation lives, from the numbers the business actually keeps. That is the quiet argument for running commerce inside the desk from day one — not features, but the permanent absence of four kinds of dispute.
The compounding benefit is not speed but consistency: one catalog means quotes, orders and invoices quote the same prices (the seam where old businesses quietly lose margin); one status trail means support answering "did my payment go through?" is reading the same state finance is; and the AI layer drafts in the same truth — a Copilot summary of payment status cites the invoice's own trail, not a guess. The free tier carries all of it at $0: conversations, CRM, quotes, orders, invoices, three seats, 100 MB (text conversations barely count; the packs meter attachments). Upgrade pressure arrives honestly — the first payment (a seat, storage, or AI credits) removes the "Powered by Onsites AI" watermark permanently — and nothing structural changes when it does, because the workflow was the product all along.
Can we really issue quotes, orders and invoices without switching tools?
Yes — Onsites Mail is the desk's document layer: one editor covering quotes, orders, invoices and contracts, drawing on one shared product catalog and the same workspace as support conversations and CRM records. The buyer is identified in the chat; the documents inherit the context.
How does the conversation become an invoice step by step?
The conversation auto-links to the buyer's record; the quote is drafted from the shared catalog; acceptance turns it into the order (same lineage); fulfillment graduates into the invoice, sent from the same editor with its own status trail: sent → seen → paid → overdue if it stalls.
Where do the product names and prices come from?
One shared catalog used by every document type — quote, order, invoice — so prices never re-type and never drift between sales and finance. Edits happen once, in the catalog.
What statuses do the documents carry?
Quotes: draft → sent → accepted or expired. Orders: confirmed → fulfilled. Invoices: sent → seen → paid, or overdue when they stall — each transition auditable in the same trail support and finance read.
Do support and finance really see the same state?
Yes — same workspace, same document lineage, same status trail: support answers payment questions from the invoice's own record, finance reads quotes and orders the support thread helped create, and AI summaries cite the trail rather than retelling it.