The first
Admin hours spent on comparison work rather than on customers.
/01 · What we understood
What we understood
Customer orders arrive as email with Excel and PDF attachments, and no two customers send the same format. Your PO admins open each one and match it by hand against the current style master, which originates in OMS and passes through Excel before anything reaches Microsoft Dynamics. Style numbers, descriptions and colours have to be reconciled by eye, and older customer files circulate alongside updated ones with no reliable way to tell which is current.
Two costs come out of this. The first is admin hours spent on comparison work rather than on customers. The second is order errors that surface later in production or shipping, when they are expensive to unwind.
The second
Order errors that surface later in production or shipping, when they are expensive to unwind.
/02 · The project
The project
We build an intake and validation service that turns an incoming customer order email into a checked, Dynamics-ready order.
Monitors a dedicated order mailbox and picks up new customer orders as they arrive
Reads Excel and PDF attachments, including scanned documents
Extracts line items: style number, colour, size breakdown, quantity and requested ship dates
Reconciles each line against the current style master exported from OMS
Applies your fixed price list, so the system makes no pricing judgement at all
Flags anything it cannot resolve, with a stated reason: unknown style, discontinued colour, superseded customer file, illegible scan, missing field
Drafts a clarification email back to the customer when a document cannot be read, ready for an admin to send
Outputs a Dynamics-ready order file for the PO admin to review and import
/03 · How it works, end to end
One customer order, from arrival to import:
01
An order arrives in the intake mailbox and the service picks it up.
02
Attachments are classified by type and format, so an Excel order sheet and a scanned PDF are handled by the right reader.
03
Line items are extracted from each attachment: style, colour, size breakdown, quantity, requested ship dates.
04
The file is version checked against previous submissions from the same customer, so a superseded sheet is caught rather than processed as new.
05
Every line is reconciled against the current style master exported from OMS. Style number, description and colour are matched, and near-misses are surfaced rather than guessed at.
06
Your fixed price list is applied. The system makes no pricing decision of its own.
07
Each line is scored. Clean lines pass through. Anything uncertain is flagged with a stated reason, not silently corrected.
08
If a document cannot be read at all, a clarification email back to the customer is drafted and queued for an admin to send.
09
The output is a Dynamics-ready order file plus a short exception summary showing what needs a human eye.
10
A PO admin reviews, adjusts anything flagged, approves, and imports.
Where the human stays
The service never releases an order on its own. A PO admin reviews and approves every order before it goes anywhere. Confidence thresholds decide what the system handles cleanly and what it escalates, and those thresholds are set with your team, not by us. The job of this project is to remove the manual matching, not the judgement.
/04 · What you receive
What you receive
An email intake service monitoring a dedicated order mailbox.
Document readers for Excel and PDF attachments, including scanned documents.
A reconciliation engine that matches extracted lines against the OMS style master export.
Price list application, driven by a configuration file your team can update without us.
An exception queue with reason codes, and a review view your PO admins work from.
Draft clarification emails for unreadable or incomplete customer documents.
A Dynamics-ready order file, in an import format agreed with your admins in week 1.
Confidence thresholds configured with your team, and documented so they can be adjusted later.
Deployment into an environment you own, with the source code delivered to you.
A written runbook and a handover session with the people who will use it daily.
/05 · What is not in this project
What is not in this project
Named explicitly so there is no ambiguity later. Each of these is a candidate for a later project.
What is not in this project
- Writing orders directly into Microsoft Dynamics. This project outputs an import-ready file. Direct write-back is deliberately held back, for the reason given in section 7.
- Any change to OMS, or migration of PLM data.
- Sales reporting, margin analysis or budget comparison.
- Natural language querying of historical sales data.
- The style recommendation engine for sales proposals.
- Production and logistics workflow changes.
What this scope assumes
Up to six distinct customer file formats, and one style master source, being the OMS export. If the week 1 mapping shows materially more than that, we raise it before we start building rather than letting you find out at handover.
/06 · How it runs
Week 1
Weeks 2 and 3
Week 4
Week 5
Five weeks from kickoff.
Process mapping and document review.
We sit with your PO admins, walk the current intake end to end, review a representative set of customer files, and agree the output import format. The mapping happens inside the project, not as a gate ahead of it.
Build.
Document extraction, style master reconciliation, price list application. Checkpoint at the end of week 3 with working output on your real documents.
Exception handling.
Flagging rules, confidence thresholds, clarification email drafts, and the admin review view.
Testing against your documents with your team, tuning based on what it finds, deployment, handover session and written runbook.
/07 · What this sets up
What this sets up
The sequencing is deliberate. Intake is the step where your data quality problem actually lives, so fixing it first makes everything downstream cheaper. Once it is running and your admins trust it:
Each is a separate project with its own scope and its own definition of done. Nothing in this proposal commits you to any of them, and we would rather earn the second project than pre-sell it.
/08 · What we need from you
What we need from you
A dedicated mailbox for order intake.
A current style master export from OMS, in whatever format it comes out in.
A representative set of recent customer order documents at kickoff, including a few you would call difficult.
A named business owner on your side, roughly two hours a week.
A mutual NDA in place before we receive any customer documents.
/09 · Separately
Separately
Timeline confirmation, fee and the criteria for handover sit outside this document. We will work those through with you once the scope above is agreed.
/10 · About Webisoft
About Webisoft
A Montreal software and AI consulting firm. 40 engineers, entirely onshore in Canada, no offshore subcontracting. Python across the team, which lines up with your existing custom stack.
Annex A: The Webisoft Operating Suite
The Webisoft Operating Suite
A set of independent modules. Every one of them is deliverable on its own, against whatever systems you already run. There is no required starting point, no required platform, and no obligation to take a second module because you took a first.
Your existing system of record stays where it is. Microsoft Dynamics, Sage, NetSuite, SAP or a custom in-house system are all fine. Odoo appears below as an option for teams that do not have a system of record yet, not as a prerequisite for anything else.
The modules
| Module | What it does | What it needs to run | Commonly paired with |
|---|---|---|---|
| Order intake | Turns customer orders arriving by email into checked, ERP-ready orders. Reads Excel, PDF and scans, reconciles against your product master, flags what it cannot resolve. | A mailbox and a current product master export | Data foundation, Finance operations |
| Sales documents | Generates quotes, proposals and estimates from your price book and past documents, so output quality does not depend on who is at the desk. | A price list and a sample of past documents | Insights |
| Customer service | Triages inbound email, drafts first responses, routes what needs a specialist, escalates what needs a decision. | A shared mailbox and your routing rules | Order intake |
| Finance operations | Payables and receivables: invoice capture and coding, matching against orders and receipts, collections follow-up. | Access to your accounting system and a sample of invoices | Order intake |
| Data foundation | Cleanup, deduplication and centralisation of records spread across existing systems and spreadsheets. | Read access to the source systems | Any module, and Insights in particular |
| Integrations | Connectors between the systems you already run: ERP, CRM, accounting, e-commerce, EDI, logistics, legacy databases. | API or database access at both ends | Any module |
| Insights | Inventory projection, demand forecasting, recommendations, and plain-language querying of your own history. | Clean historical data, either from your systems or via Data foundation | Data foundation, Sales documents |
| Custom applications | Portals, dashboards and internal tools for the places where no product fits. Built on top of whatever is already there. | A defined user and a defined job to be done | Any module |
| ERP implementation (Odoo) | A single system of record for teams still running on spreadsheets, or consolidating several partial systems. | A decision to consolidate | Integrations, Data foundation |
| Cloud and data platform | Hosting, security, Canadian data residency and model infrastructure, on AWS or Azure. | Nothing | Any module |
How they combine
Modules can be sequenced, but the sequence is a choice rather than a dependency chain.
One module, standalone.
Order intake on its own, feeding your existing Dynamics through an import file. Nothing else changes.
Two that reinforce each other.
Order intake first, then Finance operations, so a validated order and its eventual invoice are matched against the same clean record.
A data-first path.
Data foundation, then Insights, when the goal is forecasting and the blocker is that history lives in twelve spreadsheets.
A front-end on top.
Custom applications over any of the above, once there is something worth giving people a screen for.
What is not required
You do not need Odoo, or any change to your current ERP, to use any other module.
You do not need a platform or infrastructure project first.
You do not need to commit to more than one module. Each is scoped and delivered on its own terms.
Relevant to HB Connections
The project in this proposal is the Order intake module. From our conversation, the two most likely follow-ons are Insights, for the reporting and margin analysis the sales team asked about, and Sales documents, for the style recommendation engine. Both work better once intake is producing clean order records, which is the reason for the sequencing in section 7 rather than any technical dependency.
Sales Order Intake Automation
Timeline confirmation, fee and the criteria for handover sit outside this document. We will work those through with you once the scope above is agreed.