In my first weeks at Factory Software, one thing stood out in customer conversations: software was rarely the first topic. People talked about the line. What stopped, who got called in, and how long it took before anyone knew what was going on. I’ve sat in a lot of CRM meetings. They didn’t start like that.
I spent about ten years working on CRM, CPQ, and marketing automation. Sales processes, pricing, handoffs between marketing, sales, and delivery. Now I lead technical enablement at Factory Software, where we help manufacturers across the Benelux get value from industrial software. On paper it looks like a big jump, from the commercial side of a company to the factory floor.
Some things did change completely. But the things that matter most in the work turned out to be the same. This post is about both.
What changed
The buyer lives somewhere else
In CRM projects, the people I worked with sat in sales, marketing, or commercial leadership. They thought in pipeline, conversion, and quarters. Their problems were real, but when something broke, a report was wrong or a quote went out late. Annoying, sometimes expensive, rarely dangerous.
In industrial software, the buyer often sits in operations, engineering, or maintenance. They think in uptime, safety, quality, and shifts. When something breaks, a line stops, a batch gets scrapped, or someone gets called out of bed at three in the morning. That changes how people listen. A sales director will try a new tool because it might help. A plant manager asks what happens if it fails, and they mean it literally.
So people are careful. Careful, not slow. The first question is rarely “what can it do?” It’s “what’s the risk of changing something that already works?” If you answer with features, you haven’t answered the question they asked.
The expert is part of the product
In CRM, the software is usually the thing being sold, and consultants help configure it. In industrial software, the knowledge of the people implementing it matters at least as much as the software. A good consultant knows how a plant runs, what operators will put up with, and where the data actually comes from. The customer is buying that judgment as much as the licence.
That’s part of why technical enablement exists as a job. The team already knows a lot. The challenge isn’t adding more knowledge. It’s helping them use what they know with people who don’t share their vocabulary.
Time moves differently
CRM projects run on quarters. Plans get made, rebuilt, and replaced within a year. A lot of industrial systems run for ten or twenty years. Decisions made today will still be running when the people who made them have moved on.
That changes the conversation. A customer isn’t only asking whether this solves the problem now. They’re asking whether it still makes sense in 2035, whether their own people can maintain it, and whether you’ll still be around. Trust gets built over a longer horizon, and it can be lost in one bad project.
What didn’t change
The stated problem is rarely the real one
This was the first thing I recognised. In CRM work, a company would say “we need a better CRM” when the real problem was a handoff nobody owned or a sales process nobody followed. The system was carrying the symptom.
Industrial software has the same pattern. “We need better visibility” can mean the data doesn’t exist, the data exists but nobody trusts it, or everyone sees the problem but nobody is allowed to fix it. Each one needs a different answer. And just like before, the only way to find out is to talk to the people doing the work, not only the people who sign.
The buyer still has to sell it internally
Almost every deal I worked on in CRM was decided in a meeting I wasn’t in. The commercial director had to explain the decision to finance, to IT, to the board. If they couldn’t explain it simply, the project stalled, however good the demo was.
It’s the same here. The plant manager who is convinced still has to convince someone else. Finance wants to know the cost of doing nothing. IT wants to know what it touches. Operators want to know what changes on their shift. The person you talk to needs a story they can retell, and building that story with them is most of the work. I wrote more about that in How I work.
Adoption is the hard part
In CRM, go-live was never the finish line. A system could be configured perfectly and still fail because people kept their own spreadsheets. I saw it often enough to stop being surprised.
On the factory floor the stakes are higher, but the pattern is the same. If operators don’t trust the screen, they keep the clipboard. If the supervisor doesn’t use the data in the morning meeting, nobody else will either. The software only matters to the extent that it changes how people work on a normal day.
Translation is a real job
The most useful thing I brought with me isn’t CRM knowledge. It’s the habit of translating between people who describe the same problem in different words. In my old work, that was sales and IT. Now it’s engineering and management, or the operator and the CFO.
Technical people are often right and still unconvincing, because they answer the question they find interesting instead of the one the listener is asking. That isn’t a flaw in engineers. It’s a skill nobody taught them. Teaching it is a big part of what I do now.
What I’m still learning
The move hasn’t been seamless. There’s new vocabulary, a different pace, and a lot of history I wasn’t around for. I ask more questions in meetings than I used to. That turns out to be useful.
Same work, different floor
When I told people I was moving from CRM to industrial software, most of them assumed I was starting over. For a while I thought so too. But the work underneath is the same: find the real problem, help the buyer make a decision they can defend, and make sure it actually gets used.
The floor is different. It’s louder, and the consequences are more physical. But the people on it want the same thing the sales director wanted: to understand why the change is worth it.