Quotes and orders
Quotes and orders that arrive as email and PDF.
A request lands with an attachment. Someone opens it, works out which of your parts it means, checks stock and this customer’s terms, and types it into your system. We build the system that reads the request, matches it to your catalogue, and drafts the quote or the order. Your team checks it and releases it.
Intake run
Continuous
It lands
Email, PDF, form, or the note from a phone call.
Read
your catalogueParts, quantities, terms and dates pulled out.
Match
Checked against stock, pricing and this customer's terms.
Draft
The quote or the order, written into your system.
Your team
Checks it and releases it.
The run your team gets after handover.
How it goes now
- Requests spread across inboxes, forms and phone notes
- Each one waits for whoever is least busy
- Line items retyped from a PDF into the ERP
- Stock and terms checked in a second and third window
- The buyer has two other quotes by the time yours is written
How it goes after
- Every request in one queue, whatever the channel
- The draft is ready before anyone has opened the email
- Line items matched to your catalogue, with the source shown
- Anything doubtful held back and flagged, not guessed
- Your team spends the time on price and relationship
Someone in your company has probably already tried this.
This is the job people are most likely to have built a version of themselves, and the versions usually work. They stop working when the person who built it is away, when a supplier changes a form, or when nobody can explain why it did what it did last Tuesday.
What is on sale here is the same idea, evaluated against your real requests before it goes live, documented, owned by you, and handed to a team that has been trained to change it. If you already have a working version, bring it to the diagnosis. Hardening what exists is often cheaper than starting again, and we will say so if it is.
Exactly what the build includes
- Every request captured in one queue, whichever channel it arrived through
- Parts, quantities, dates and terms read out of the attachment, not retyped
- Matched against your catalogue, your stock and this customer's agreed pricing
- The quote or order drafted directly in the system you already run
- Anything ambiguous held back and flagged, with the reason, instead of guessed
- A person checks and releases. Nothing is sent or booked on its own.
Acceptance criteria, for example
Agreed in writing before the build. The system ships when it meets them; until then, we keep working at no extra cost.
- Time to quote: measured from arrival to sent, before and after
- Extraction accuracy: line items read from a sample of real requests, checked against the source
- Escalation quality: the system holds back the requests a person should see, and few others
- Rework: how often a released quote has to be corrected afterwards
Works inside your stack
The draft is written into the system your team already opens every morning.
ERP and Warenwirtschaft
- SAP Business One
- Microsoft Dynamics 365 Business Central
- Sage 100
- weclapp
- JTL-Wawi
- Xentral
Inbox, CRM and documents
- Microsoft 365 / Outlook
- Google Workspace
- HubSpot
- Pipedrive
- Salesforce
- Scanned and emailed PDFs
Different stack? That is a diagnosis question, not a blocker. If it has an API or a supported import, we can build into it.
True of every build we do
- Fixed price
- Quoted once after the diagnosis, invoiced once. No day rates and no running meter.
- Criteria in writing
- We agree what the system has to do, and how it will be measured, before anything is built.
- It ships when it passes
- Tested on your data against those criteria. Until it passes, we keep working at no extra cost.
- You own everything
- Code, prompts, data, accounts, documentation. Yours from day one, so there is nothing to be locked into.
- Your team runs it
- Training and a handover built for people who did not write it. If you never speak to us again, it keeps working.
How you buy it
The same three steps for every job we take on. You can stop after either of the first two.
Step 1
Diagnosis
EUR 4,900, two weeks
What this work costs you today, what a system would take off your team, and a fixed quote with the acceptance criteria written down. Credited in full against a build that starts within 90 days. If it finds no job worth building, you get the fee back.
Step 2
Build
from EUR 14,900, fixed after the diagnosis
Built into the tools you already run, so there is no new platform to adopt. Tested against the criteria we wrote down, on your data. It ships when it passes, with training and full ownership.
Step 3
Run
optional
The answer to who owns it after we leave: monitoring, exception handling, and changes as the business changes. You own the system either way and your team is trained to run it, so this is a choice rather than a dependency.
See it in your industry
Questions buyers ask
Our requests are messy. Scans, forwarded threads, handwriting on a PDF.
That is the normal case and it is why this starts with a diagnosis on your real inbox rather than a demo on clean files. Some of that mess is readable and some is not. Two weeks tells you which, and the honest answer is sometimes that a share of requests will always need a person, in which case the build is aimed at the rest.
What happens when it is not sure?
It stops and says why. A system that guesses at a line item is worse than no system, because someone has to check all of them anyway. Holding back the right requests, and only those, is one of the criteria we hold the build to.
Does it send quotes to customers by itself?
Not unless you decide it should, and most teams do not. The default is that it prepares and your team releases. That keeps the commercial judgement, the pricing exceptions and the relationship with a person.
Someone here already built something like this.
Often true, and it is usually a good sign. The versions people build themselves tend to work until the person who built them is on holiday, or the format changes, or nobody can say why it did what it did. What you buy here is the evaluated, documented, owned version of that idea, with the criteria written down and your team trained to change it.
Will it work with our ERP?
If it has an API or a supported import, yes. We build into the system you run rather than beside it, because a second place to look is not a saving. Which parts of your ERP are safe to write to is a diagnosis question and worth answering carefully.
Bring five real requests.
Including the two worst ones. Twenty-five minutes with the actual attachments tells us whether this is worth building and roughly what it would cost.