The Factory Floor Has More Data Than Your CRM. It’s Just Not Talking.

At 2:14 a.m., a furnace on line three drifts outside its temperature window for eleven minutes. The historian logs it. The quality system flags the batch for inspection. The shift supervisor makes a note.

At 10:30 a.m., a sales rep opens the CRM, sees that the customer’s order is “In Production,” and confirms Friday delivery on a call.

Both systems are working exactly as designed. That’s the problem.

Most manufacturers already own more operational truth than they know what to do with. It lives in PLCs, SCADA screens, MES records, historians, quality logs and maintenance tickets. Meanwhile, the CRM — the system every customer-facing decision runs through — holds a few dozen fields per account, updated whenever someone remembers to update them. The factory floor has more data than your CRM. It’s just not talking.

The asymmetry nobody designed on purpose

Put the two worlds side by side and the gap is obvious.

	Factory floor (OT)	CRM (IT / commercial)
Data volume	Continuous — sensor readings every second or faster	Episodic — a handful of updates per deal
Time grain	Milliseconds to minutes	Days to weeks
Primary identifier	Asset, tag, work order, batch or heat number	Account, contact, opportunity, case
Who owns it	Plant engineering, maintenance, quality	Sales, service, marketing ops
Typical protocols	OPC UA, Modbus, MQTT, vendor-specific	REST APIs, webhooks
What it knows	What is actually happening	What someone said would happen

Neither side is wrong. They were simply built by different teams, for different jobs, decades apart. Operational systems were designed to keep machines running safely — often deliberately isolated from business networks. CRMs were designed to track relationships and pipelines. Nobody sat down and said, “Let’s make sure these two never share context.” It just happened, one purchase order at a time.

Why the two systems don’t talk

“Just integrate them” sounds easy until you look at what actually stands in the way.

1. They don’t share a key

A CRM thinks in customers and orders. A machine thinks in tags and timestamps. To connect “temperature excursion on furnace 3” to “Acme Ltd’s Friday shipment,” you need a chain: sales order → work order → production batch → asset → sensor reading. In many plants, at least one link in that chain lives in a spreadsheet, a paper traveller or someone’s head.

2. They don’t share a clock

Raw machine data is far too granular for anyone in sales or service. Nobody wants ten thousand vibration readings on an account page. The data has to be summarised into something with business meaning before it’s useful — and deciding what “meaning” is takes people from both sides in the same room.

3. They don’t share a vocabulary

Tag names like L3_FRN_TMP_PV_02 mean something to a controls engineer and nothing to an account manager. Without a shared model of assets, lines and products, every integration becomes a one-off translation job that breaks the next time someone renames a tag.

4. They have good reasons to stay apart

Operational networks are segmented for safety and security, and frameworks like ISA/IEC 62443 exist for a reason. Any connection has to respect those boundaries — data flowing out of the plant in a controlled, read-only way, never a path for business systems to reach in.

5. Nobody owns the middle

The plant team owns the machines. The commercial team owns the CRM. The space between them — the part that would actually make them talk — usually has no owner, no budget line and no roadmap.

What the silence is costing you

The cost rarely shows up as a single line item. It shows up as friction everywhere customers touch the business:

• Promise dates disconnected from reality. Sales commits to delivery windows based on what the CRM says, not on actual line capacity, scrap rates or a machine that’s been down since Tuesday.
• Customers finding problems first. A quality deviation is logged on the floor, but the account team hears about it when the customer calls — angry — about a rejected shipment.
• Service flying blind. When a complaint comes in, service reps can’t see the batch history, test results or process conditions behind the parts the customer received. Root-cause becomes an email chain.
• Missed early warnings. Rising defect rates on one customer’s product family, or repeated rework on their orders, are strong signals of account risk. They just never reach the people managing the account.
• AI pilots built on half the picture. Forecasting, churn or pricing models trained only on CRM data are guessing about the very thing that determines customer outcomes: what happened in production.

Your CRM records what you promised. Your factory floor records whether you kept it. Until those two meet, every customer conversation is half-informed.

What “talking” actually looks like

Making the factory floor talk to your CRM doesn’t mean piping sensor streams into account records. That just creates noise. It means building a thin, governed layer that turns raw operational data into a small set of business events that commercial teams can act on.

A few examples of what that sounds like in practice:

• “Order 4471 is at risk of missing its ship date.” Triggered when the work order falls behind schedule or its line goes down — surfaced on the opportunity before the customer asks.
• “Batch B-2290 deviated from spec.” Linked automatically to every customer whose order contained that batch, with a service case opened proactively.
• “Quality certificate available.” Test results and certificates attached to the order record, so the account team can send them without chasing the lab.
• “Defect rate on this customer’s parts is trending up.” Rolled into an account health score alongside support tickets and payment history.
• “Capacity available on line 2 next week.” Fed into quoting, so sales can offer realistic lead times — or confidently promise faster ones.

Notice what each of these has in common: they’re answers to questions someone in sales or service already asks. That’s the test. If an integration doesn’t answer a question a real person has, it’s just plumbing.

The architecture, in plain terms

The technical details vary by plant, but the shape is consistent:

1. Collect, read-only. Pull data from historians, MES and quality systems through a secure gateway or industrial DMZ. Nothing from the business side writes back into control systems.
2. Contextualise. Map raw tags to a shared model of sites, lines, assets and products — often called an asset model or unified namespace — so L3_FRN_TMP_PV_02 becomes “Line 3 furnace temperature.”
3. Join. Connect production records to commercial ones through the order → work order → batch chain. This is usually the hardest and most valuable step.
4. Distil into events. Define a short list of business events with clear thresholds and owners. Fewer, sharper events beat a firehose.
5. Surface where people already work. Push events into the CRM as fields, alerts, tasks or cases — not into yet another dashboard nobody opens.

Where to start (without boiling the ocean)

The fastest way to stall is to aim for “full OT–IT convergence” on day one. The fastest way to show value is to start with one question.

1. Pick one question your commercial team can’t answer today. “Will this order ship on time?” is a strong first candidate. So is “Which customers received parts from a flagged batch?”
2. Trace the join keys. Walk the chain from customer order to machine data and find every place it breaks. Fixing those breaks is most of the work.
3. Land the data somewhere governed. A central store where operational and commercial data can be joined, with clear access controls and lineage.
4. Define three to five events, not fifty. Agree thresholds with plant and commercial leads together.
5. Put them in the CRM and measure. Track whether reps act on them, whether escalations drop and whether delivery conversations change.
6. Then expand. Once one use case earns trust, the joined data becomes the foundation for the next — and the one after that.

Where AI fits in

Once production and customer data share a key, a lot of AI use cases that looked like science projects become straightforward: delivery-risk prediction, account-level quality forecasting, service copilots that can explain why a part failed, quoting assistants that understand real capacity.

But the order matters. Everyone has access to the same models. What they don’t have is clean, joined, permission-aware data connecting what the plant does to what the customer experiences. That system around the model is the real advantage — and it has to be built first.

Common mistakes to avoid

• Streaming raw sensor data into the CRM. It bloats records, slows the system and helps no one.
• Building a dashboard instead of a workflow. If insight doesn’t arrive inside the tool reps already use, it won’t change behaviour.
• Leaving the plant team out. They understand what the data means and which signals are trustworthy. Without them, thresholds are guesses.
• Compromising network segmentation for convenience. Data should flow out of OT in a controlled way — never open a door back in.
• Treating it as a one-time project. Tags get renamed, lines get added, products change. The translation layer needs an owner.

Frequently asked questions

Can factory data be connected to Salesforce or other CRMs?

Yes. Modern CRMs expose APIs and event mechanisms that can receive data from an integration layer. The work isn’t in the CRM connector itself — it’s in collecting, contextualising and joining operational data so that what arrives in the CRM is meaningful.

Is it safe to connect OT systems to business software?

It can be, when designed properly. The standard approach is one-directional, read-only data flow out of the operational network through a secured gateway or DMZ, following the zone-and-conduit principles in standards like ISA/IEC 62443. Business systems should never have a path back into control systems.

Do we need an MES before we can do this?

Not necessarily. An MES makes the order-to-batch link much easier, but plants without one can often start with historian data, ERP work orders and quality records — as long as there’s a reliable way to tie production runs back to customer orders.

How long does a first use case take?

It depends heavily on how clean the join between orders and production records already is. Scoping a single, well-defined question — like delivery risk on open orders — keeps the first phase focused and lets you prove value before expanding.

The bottom line

Your factory already knows which orders are slipping, which batches are suspect and which customers are about to have a bad week. Your CRM is where those customers are managed. Connecting the two isn’t a moonshot — it’s a data engineering problem with a clear starting point: one question, one join, a handful of events, delivered where your team already works.

The data is already there. It’s time to get it talking.

Want to find out what your factory floor could be telling your sales and service teams? Talk to us about mapping your first use case.