How we reduce a 3‑hour task to 30 minutes

A manufacturer of custom accessibility equipment came to us after investing six years in design automation. They had made real progress with a third-party configurator, but each order still took a designer three to four hours, and a designer could get only two or three orders out per day.

We reduced that to 30 to 45 minutes of engineering time per order.

The gain didn’t come from making designers faster. It came from building their design rules into a system that could predict the design, and from understanding the work well enough to know which parts needed a designer at all. In my experience, this is where most design automation projects go wrong. They automate the process as it’s documented rather than as it’s actually performed, and they try to speed up the existing steps instead of asking why those steps take three hours in the first place.

That’s also why “How much faster can you make this?”, the question we hear most often, is the wrong place to start.

A three-hour task is mostly execution

When a company tells us a task takes three hours, our first job is to find out what’s inside those hours. It’s almost never a single activity. It’s a few minutes understanding requirements, a design decision or two that needs an experienced person, and then a long tail of execution: finding information, opening files, copying data, changing parameters, generating geometry, producing drawings, exporting formats, naming files and checking the results.

All of that work may be necessary. Very little of it requires judgment, by which we mean decisions that can’t be reduced to a documented set of rules. The rest is the mechanical execution of decisions that were made long ago and are made the same way every time.

That split is the foundation of how we work. We don’t try to make the designer faster. We arrange things so the designer spends 30 minutes on the part that needs a designer, and the system handles the other two and a half hours.

Automation stalls on the process nobody wrote down

It may sound odd coming from a company that builds automation, but the first step of a good project isn’t writing code. It’s sitting with the people who do the work and watching them do it.

The documented process and the real one are rarely the same. Experienced staff have shortcuts nobody wrote down. There are exceptions missing from the SOP, and decisions that look simple from the outside but rely on years of knowledge. There are also steps people perform because “that’s how we’ve always done it.” Some exist for good reason, some are left over from an older system, and some can simply go. You can’t tell which from a process diagram.

Our accessibility equipment client is a good example. They had a configurator in place, but it wasn’t making design decisions. Designers still placed every component into the model by hand, working out the layout through trial and error and their own experience. The documented design rules guided that work, but it was the designer, not the software, applying them.

Their veteran designers also knew rules the documentation didn’t capture. That knowledge existed only in their heads.

So we started with their most knowledgeable designers and learned the ins and outs of their product from them. At this stage our work looks more like process engineering than software development. We want to understand the logic of the task before deciding what technology should do with it: what becomes software logic, what stays a human decision and what becomes an automated check.

Rules configure. Purpose-built systems predict.

A configurator assembles what a designer tells it to. It doesn’t decide where each component should go on an installation it has never seen. Every installation is different, so for that to happen, the design rules have to be built in a way that lets the system make predictions on its own.

So, drawing on our 15 years in the business, we built a single system centred on the installation itself. It replaced both of the partial solutions they had been using: a site-modelling tool and a configurator. The new system reads the field measurements and builds a 3D model of the installation. From that model, it predicts the ideal layout for each order, then automatically assembles and sizes every part the product needs and generates full 3D models of the system along with production drawings. At each step, the engineer can deviate from the system’s prediction when their judgment says otherwise.

The prediction algorithms are built on all of their design rules, documented and undocumented. The undocumented rules from their veteran designers work in the background, without prompting the designer, and give the predictions the nuance that experience normally supplies.

That’s what bespoke means in practice. An off-the-shelf configurator is built to assemble the options you give it. This client needed a system that could predict the design from their product, their data and the knowledge of their best designers. It doesn’t need artificial intelligence. It needs the right logic in the right place, and the judgment to know which decisions can be handed to the computer and which should stay with a person.

Designers should validate automated work, not manually produce it

The biggest change is to the designer’s role. In a manual process, the designer creates the result. In an automated one, the system creates it and the designer reviews it.

That changes what limits their capacity. Manually, it’s how fast they can produce models, drawings and parts lists. With automation, it’s how quickly they can review the output and handle the exceptions. When an order takes 30 minutes of a designer’s time instead of three hours, the same person has the capacity for several times the work.

Two other things change along the way. The first is context switching. A designer moving between CAD, spreadsheets, PDFs, email and databases loses more than the minute each switch takes. They lose their place, and every handoff is a chance for an error. When information flows between systems automatically, the designer stays focused on the design. The second is waiting. Automated processes still take computing time, but no one needs to watch them run. The designer submits the job, moves on and comes back to finished output.

None of this means trusting the computer blindly. Computers are excellent at applying rules, including the wrong rule, very consistently. A good system handles the normal case and flags the unusual one: the out-of-range dimension, the configuration that causes a manufacturing problem, the design that satisfies every rule and is still a poor engineering solution. Instead of searching for problems, the designer is handed the ones that need attention. The computer handles the predictable; the person handles the uncertain.

A designer’s time is worth more than their wage

The obvious way to value automation is to multiply the minutes saved by the designer’s hourly cost. At $60 an hour, saving 150 minutes is worth $150 per task. It’s a real saving, but it’s usually not the most important number.

A designer’s wage is what it costs to employ them. The value of their time is what else they could be doing with it: helping sales win a major contract, developing a new product, solving a manufacturing problem. The more skilled the person, the more expensive it is to spend their expertise on repetitive work.

It also changes what work you can say yes to. Overloaded design teams naturally get selective. They delay small jobs, avoid customization and tell sales that some requests aren’t worth pursuing. When the design effort drops, that work becomes worth taking. And good designers stay longer when they spend their days solving problems rather than repeating production work.

Three hours to 30 minutes is only the start

You don’t need to automate everything on day one. Start with the most repeatable, highest-volume parts of the process. Automating 70 percent might take a task from three hours to one. Once the system is in production, you learn where the remaining time goes and what to automate next.

The designers who do the work today are central to this. They know where the frustrations are, what can go wrong and what a good result looks like. Once the system is running, they’re the ones who spot exceptions and refine the rules. Over time, the designer teaches the system what can be standardized, and the system gives the designer time for what can’t.

When we say we can reduce a three-hour task to 30 minutes, we’re not claiming a clever shortcut. We mean we’ve found the work that doesn’t need a skilled person’s attention, built a system that does it consistently and moved the engineer into a reviewing and decision-making role. Do that once and you’ve improved a process. Do it across dozens of processes and thousands of orders and you’ve changed the economics of your design organization.

Growth no longer has to wait on engineering

For most engineer-to-order manufacturers in 2026, the limit on growth isn’t demand. It’s the design department. Every custom order passes through engineering, and every order still takes as long as it did last year. When sales double, design hours double with them. That means hiring for roles that take months to fill and longer to train, while lead times stretch in the meantime.

Taking design time from three hours to 30 minutes breaks that link.

For leaders trying to scale, revenue can grow faster than the design team. The next doubling of orders doesn’t have to mean doubling the department. Your current team absorbs much of it, and new hires go to work that actually needs them.

For leaders bringing a new product line to life, the launch no longer competes with existing orders for the same engineers. Its design rules can be built into the system from the start, so the new line can scale from its first order instead of becoming one more queue in engineering.

For sales, it means shorter lead times, consistent designs and the ability to say yes to custom work that used to be turned away.

And for the business as a whole, the knowledge of your best designers stops being a single point of failure. It lives in a system that works the same way on every order, whoever is handling it and whoever retires next.

That’s the real return on design automation. It isn’t 150 minutes saved per order. It’s a business whose growth is no longer capped by how many designers it can hire.