The pain sits in the office, not on the floor
Walk the back office of almost any job shop, contract manufacturer, or OEM and the complaints sound the same regardless of what the plant actually makes. An RFQ arrives as an email with a PDF drawing attached, and someone has to open it, read the tolerances, check them against a part history that lives in three different places, and get a number back before the buyer moves on to the next name on their list. A purchase order lands with a revision bump nobody flagged out loud, and it only surfaces weeks later on the shop floor when the traveler still shows the old spec. A plant manager needs Monday morning's output, scrap, and downtime numbers, and gets them from an ERP export, an MES screen, and a supervisor's handwritten note that do not add up to the same total.
This sits underneath the broader view of AI in manufacturing operations: that page covers the whole picture, including where an agent's judgment is the right tool. Here we're zeroing in on one layer of it — the fixed, repeatable pipelines that workflow automation is built for, where the steps are known and the value is in never skipping one.
None of this is difficult work on its own. It is high-volume, interruption-heavy work that depends on someone remembering to do it correctly under deadline pressure, on every job that moves through the plant, every single day. That is precisely the shape of problem a defined pipeline solves — read the document, check it against what you already know, and only stop for a person when the situation genuinely calls for judgment.
What the system actually does, day to day
Once a workflow like this is live, most of the plant never notices it running. It sits on a shared inbox or a document folder, watching for the kind of message that used to need a person to open it first.
- A PDF, a scanned drawing, or a spec sheet arrives as an attachment, and the system reads it — the part number, the revision, the tolerances, the quantity, the requested delivery date.
- It checks what it found against your ERP: has this part been quoted before, does the revision match what is on file, is there an existing job this relates to.
- It fills in a structured record — a quote request, an order line, a shift figure — in the format your team already works from, not a new screen nobody asked for.
- Anything that does not resolve cleanly — a tolerance that has never appeared before, a revision that does not match, a number that does not tie out — gets flagged and routed to the person who should see it, with the reason attached.
- Routine confirmations, follow-ups, and status updates go out on their own; anything touching price, a quality disposition, or a customer commitment waits for a person to approve it.
The point is not to remove your estimators, planners, and quality leads from the loop. It is to stop their day from being eaten by re-typing, chasing, and reconciling, so the judgment calls that actually need a skilled person get their full attention.
Three workflows, step by step
RFQ intake, from inbox to structured quote request
- An RFQ lands in the quoting inbox as an email with a PDF drawing and a spec sheet attached — the shape almost every job shop sees dozens of times a week.
- The system reads the attachment, pulling the part number, material, tolerances, quantity breaks, and requested lead time out of a document that was never structured data to begin with.
- It checks the extracted spec against your part history and current capability — has this exact part run before, does a comparable one exist, is there open capacity in the window the buyer is asking for.
- Where the match is clean, it assembles a structured quote request in your quoting or ERP system, priced against your existing rules, ready for an estimator to review rather than build from scratch.
- Where it isn't clean — a tolerance nobody has quoted before, a new customer, a material outside your normal range — it flags the RFQ for an estimator with the reason attached, instead of silently guessing.
- Nothing goes back to the buyer without a person seeing it first if it touches price. What the automation buys back is the stretch of re-typing and cross-checking that used to happen before an estimator even started thinking about the number.
Order acknowledgement and spec-change propagation
- A purchase order or an engineering change notice arrives as an email attachment, a portal upload, or a scanned fax — still common at this stage of a plant's workflow.
- The system extracts the part number, revision, quantity, and delivery date, and checks them against the original quote and what is currently on file in the ERP.
- If everything matches, it books the order and sends the acknowledgement back to the customer without anyone touching it.
- If the revision has moved, the quantity has changed, or a delivery date has shifted, it does not bury the difference inside a confirmation email — it flags exactly what changed and pushes that change to the people who need to see it before it reaches production: planning, quality, and whoever owns the traveler.
- That handoff is normally where things break. A spec change caught in an inbox but never reflected in the routing document is how the wrong revision ends up on the shop floor weeks later. Propagating the change at intake, not after someone notices a mismatch, is the actual point of the automation.
Production and shift reporting, reconciled instead of re-typed
- Output, scrap, and downtime figures get pulled from wherever they actually live — an MES export, a scheduling system's report, a supervisor's end-of-shift form or email.
- The system matches the entries against job and work-order numbers, the way a planner would if they had the time to check every line by hand.
- Where two sources disagree — a scrap count that does not match the material pulled, a downtime code missing from one system but not another — it flags the mismatch instead of averaging it away or picking one number arbitrarily.
- A single reconciled report lands in the plant manager's inbox before the next shift starts, with the disagreements called out rather than hidden inside a total that looks clean but isn't.
The same pattern, three more places it shows up
Non-conformance reports and quality documentation
When a non-conformance gets raised, the automation drafts the report against your existing template, pulls in the lot, job, and prior-incident history automatically, and routes it to the right approver. It does not decide the disposition — that stays with your quality team — but it removes the blank-page problem and the minutes spent hunting for context that should already be sitting next to the form.
Supplier PO chasing and delivery-date confirmation
Instead of a buyer working down a spreadsheet of open POs by hand, the automation sends the follow-up email, chases the outstanding certificate of conformance, and logs the confirmed delivery date once a supplier replies. Vendors who go quiet past a set point get surfaced as an exception with the full history attached, so the buyer's time goes to the suppliers actually causing a problem.
Warranty claim intake and traceability lookups
A warranty claim usually arrives with a serial number and a complaint, and not much else. The automation traces that serial or lot number back through your records to the original job, the material lot, and the inspection data, and assembles the case file before anyone starts investigating — instead of a technician starting from a blank spreadsheet every time.
What this is not
This page is about the office side of a plant, not the floor. Calfy does not build computer vision for inspection or predictive maintenance for equipment — both are real, valuable disciplines, but both require sensor infrastructure, historian data, and a hardware relationship that sits outside what we build. If what you actually need is a camera watching a line or a model predicting a bearing failure, that is a different vendor and a different conversation, and we would rather tell you that on the first call than stretch a back-office system to cover it. What we build is the pipeline around the paperwork: quoting, order intake, reporting, quality documentation, supplier communication, and warranty traceability — the coordination work that surrounds the job, not the machine running it.
Fitting into your ERP, MES, and the spreadsheets in between
An automation like this is only as good as its reach into the systems your plant already runs, so integration is where the real engineering effort goes, not an afterthought once the workflow is designed.
Connection. We connect to your ERP and MES through an API where one exists, and through a scheduled export, a shared database, or a monitored inbox where it doesn't. Manufacturers commonly run a mix of a modern ERP, an older MES, or no MES at all, tied together with spreadsheets nobody particularly wants to touch — that mix is normal, not a blocker to starting.
Documents as the input. Most of what triggers these workflows arrives as a PDF, a scan, or an email, not clean data. Reading that reliably — a drawing, a spec sheet, a scanned PO — is the harder half of the engineering work, and it gets built and tested against your actual documents before anything goes live, not a demo dataset.
Reliability over cleverness. A workflow that fails silently is worse than doing the task by hand, because everyone keeps trusting a process that has quietly stopped running. These are built to fail loudly instead — an error flagged, a person notified — the same discipline behind every workflow automation engagement, manufacturing or otherwise.
Where judgment enters. Some of what shows up in a manufacturing back office — a quality disposition, a pricing exception, a warranty determination — needs a person's judgment, not a fixed set of rules. Where that is the actual shape of the problem, the right tool is closer to an AI agent built for manufacturing than a workflow automation, and we'll tell you which one your situation needs rather than sell you the one we happen to be scoping.
Finding what already exists. A fair amount of this work depends on finding the right drawing, spec, or prior job in files that have accumulated across systems for years. That retrieval problem is the same one behind our knowledge systems work generally. For the underlying idea of a defined, repeatable pipeline like the ones described here, see what an AI workflow actually is.