What Manufacturing Taught Me About Building Better CRM Systems

My first career had nothing to do with software. I spent years in production and manufacturing environments, working out why processes weren't hitting their targets and designing systems that worked better. It was hands-on, detail-oriented work, the kind where the gap between theory and reality is immediately and expensively obvious.

I didn't know it at the time, but that experience shaped everything about how I approach Salesforce implementations today.

Waste is waste, wherever you find it

In manufacturing, waste has a precise definition: any activity that consumes resources without adding value. Lean methodology is built around identifying and eliminating it, unnecessary movement, waiting time, overproduction, defects. The goal is a process where every step adds value and nothing is done twice.

When I look at a Salesforce org today, I'm looking for the same thing. Fields that nobody fills in. Approval processes with seventeen steps when three would suffice. Reports that take twenty minutes to run and answer questions nobody is actually asking. Data entry that duplicates work happening somewhere else.

This is waste. It costs time, it erodes trust in the system, and it accumulates silently until the whole thing feels too heavy to move.

Design for the people doing the work, not the people watching

One of the most important lessons from the factory floor is that the people closest to the process know things that managers don't. The person operating the machine knows exactly where the friction is, where the workarounds are, and what would make their job easier. They're rarely asked.

The same is true in Salesforce implementations. The users entering data every day know where the system doesn't match reality. They know which fields are confusing, which steps feel unnecessary, and what information they actually need to do their job.

When implementations fail, it's almost always because this knowledge was never gathered, or was gathered and then ignored in favour of what someone further from the work thought was best practice.

The best CRM designs I've been involved in came from spending time with the people doing the work before writing a single requirement.

Failure modes should be designed out, not trained around

In good manufacturing environments, processes are designed so that mistakes are difficult to make. Jigs, fixtures, visual management systems, the goal is to make the right action easier than the wrong one. You don't rely on people being more careful. You change the system so that careful doesn't have to mean perfect.

I apply the same thinking to Salesforce. Validation rules, sensible defaults, guided data entry, automation that handles the steps people forget, these aren't nice-to-haves. They're how you build a system that stays healthy over time without constant intervention.

The through-line

Salesforce is fundamentally a process tool. It's a way of encoding how your organisation works, making that work visible, and creating the conditions for better decisions. When it's designed well — around real processes, real users, and real failure modes, it becomes a genuine operational asset. When it's designed poorly, it becomes the most expensive spreadsheet you've ever bought.

Everything I learned about process design before I ever logged into Salesforce made me better at the work I do now. The language is different. The principles aren't.

If you're thinking about a new implementation, a system redesign, or just want to talk through a process challenge, I'd enjoy the conversation. Get in touch at dan@danedwardsconsultant.com.