From order to shop drawings in 20 minutes: a product configurator case study

A US manufacturer of made-to-order panel products used to spend three to five days of CAD work on the drawing package for each order. Today the package is generated in about 20 minutes, and the engineer reviews it instead of drafting it.

This case study explains how a product configurator connected to automated shop drawings made that possible, what we built, and what we would tell any manufacturer who wants the same result. The client is under NDA, so the product details are generalized. The numbers are theirs.

The problem: every order is a small engineering project

Made-to-order manufacturing has a familiar bottleneck. No two orders are the same size or have the same options, so each one passes through an engineer twice.

Before the sale, someone has to confirm the configuration can be built and what it costs. After the sale, an engineer rebuilds the model, lays out the sheets, adds dimensions and prepares the bill of materials. In this case that second pass took three to five days per order.

The cost is more than hours. The same numbers are typed into a quote, a CAD model and a bill of materials by different people, and the queue for drawings grows with every sale.

The approach: one configuration, four outputs

The idea is simple to state. Capture the order once as structured data, and derive everything else from it: the price, the bill of materials, the 3D model and the drawings.

1. Sales enters the order dimensions and options in a web app.
2. Engineering rules check the configuration and select the parts.
3. A 3D model is rebuilt from the manufacturer's own CAD parts. Price and bill of materials update live as the order changes.
4. One click generates the dimensioned drawing package, the bill of materials and the 3D model for production.
5. The engineer reviews the package and releases it.

Sales and the engineer each touch the order once; everything between them is the engine.

Nobody retypes anything between the quote and the shop floor.

What we built

Our part was the engine that turns a confirmed order into a model and a drawing package. The ordering web app is run by the client's platform team, and we integrated with it.

The engine is a Revit add-in driven by parametric families. The families hold the product geometry and the way each part responds to the order's dimensions and options. The add-in assembles the model, creates the views, places them on sheets and annotates them.

A few facts about the output:

• Each order produces four sheets from four templates.
• All sheets are merged into one PDF, so production receives a single file.
• Views and sheets are generated automatically across the many configurations the product allows.

The team was small: a project manager, an add-in developer, a developer for the families, a QA engineer who tested releases across configurations, and an engineer for the server side.

The result

One more result matters for the long term. When the manufacturer launched a new product line, the existing engine was extended to cover it. The second product did not start from zero.

What makes drawing automation hard

Creating views is the easy part. Four things decide whether engineers trust the output.

Dimensions that stay readable. A dimension string that looks right on a small panel overlaps a tag on a large one. Placement rules have to work at both ends of the size range.

Scale and layout. A view that fits its sheet at one size overflows at another. The engine has to pick scales and positions per order.

The configuration space. Ten options with a few values each give thousands of combinations. Nobody can check them by hand, so the test set has to be chosen to cover the boundaries.

The exceptions. Some orders fall outside the rules. The system should say so clearly and hand them to the engineer, not produce a confident wrong drawing.

Five lessons for manufacturers

1. Start from the finished drawing package. Collect real packages your team has released and define the templates from them. The model exists to serve the drawings.
2. Your engineer owns the rules. We encode them. Wherever possible, keep rules in tables the engineer can read and change.
3. Keep the review step. The goal is an engineer who checks in minutes, not a process with no engineer.
4. Begin with one product line. Choose the one with the most orders and the clearest rules.
5. Plan for the second product on day one. Parts, templates and rules organized as a library make the next product an extension.

Is your product a fit?

This approach works when the product varies by dimensions and options inside known rules, is assembled from standard parts, and has a drawing package with a predictable structure. Barriers, railings, facade panels, stairs, glazing, millwork and signage usually qualify.

It is a poor fit for one-off engineered designs where every order needs new thinking.

You can try the idea on our own demo. Price it, it's already drawn is a panel pricing calculator we built to show the principle.

To find out what this would take for your product, book a Feasibility Review. Bring one product, a few sample CAD parts, one or two released drawing packages and the spreadsheet you price from. You get a written verdict on what can be automated and where the risks are. Related work is described on our web applications and plugin development pages.

FAQ

Do we have to change our CAD system?

No. The configurator is built around your existing standard parts, supplied as STEP or native CAD files, and the rules your engineer already applies.

Can a configurator send orders to our ERP or CRM?

Yes. Orders, bills of materials and prices can be passed to an ERP or CRM through its API.

What happens to orders that break the rules?

They are flagged and go to the engineer, as they do today. Automation takes the standard orders so the engineer has time for the unusual ones.

How do we know the generated drawings are correct?

The drawings follow the rules that were encoded and tested across a set of configurations. An engineer still reviews each package before release.