"So how much does that save, per week?" The design engineer who was just enthusiastically describing automatic exporting and self-filling title blocks has no answer. The managing director nods politely, slides the proposal to the bottom of the pile, and the meeting moves on to the quote for the new press brake. Sound familiar? Then what was missing was not enthusiasm, but a case.
A good business case for CAD automation fits on a single page and answers three questions: what does the current way of working cost, what does the solution cost, and when is that earned back. In this article you build that case step by step, including a sensitivity check and the soft benefits you cannot capture in a number. It does not matter whether you have your eye on a toolbox like Thundercad, a drawing generator or your own scripts: the outline is the same.
Think like your management, not like an engineer
Management does not judge your proposal on features but on return and risk, and compares it with everything else asking for budget: an extra fitter, maintenance on the saw line, a new company van. In that comparison, "it saves a lot of time" is the same as no answer: it cannot be verified, cannot be compared and cannot be defended to the accountant.
Your job, then, is translation. From clicks and export steps to hours, from hours to money in the method your own finance department uses, and from money to a payback time with an honest margin of uncertainty. Whoever makes that translation also sets the terms of the conversation: you end up discussing assumptions and scenarios instead of whether the problem exists at all.
Step 1: measure the hours, do not invent them
The foundation under every business case is a measurement in your own practice. Have the whole team tally for two weeks how much time goes into repetitive work: exporting, correcting title blocks, transferring BOM data, searching for files. Calculate per task: times per week, multiplied by minutes per occurrence, multiplied by the number of colleagues doing it. How to set up such a measurement, and which tasks people tend to forget, is something we worked out earlier in What does repetitive work really cost your engineering team?; that outcome is the starting point for everything that follows here.
Assume, for the sake of the example, that the counter for three engineers together lands on six hours per week. That number is only usable because it was measured: management punches through an estimate without effort, but a two-week tally sheet filled in by the whole team is hard to ignore. Better to measure two tasks thoroughly than ten tasks halfway.
Step 2: translate hours into money with the rate from finance
You do not invent amounts yourself. Ask whoever runs finance for the internal hourly rate of an engineer, the fully loaded rate including workplace and overhead, not just the salary. Multiply the measured hours per week by that rate and by the number of working weeks, and you have the yearly cost, expressed in your own organisation's figures.
Also spell out where the freed-up hours go, because they do not leave the payroll. They shift to work that currently sits waiting: quotes that go out late, lead times that could be shorter, overtime in peak weeks that comes down. For management, that shifting story is often more convincing than the saving itself, because it touches revenue rather than cost.
The strongest case is a measurement in your own practice. Run a one-month trial with Thundercad and tally what it saves: then you present your own figures instead of a brochure.
Try 30 days freeStep 3: put the investment next to it and calculate the payback time
Be as thorough on the cost side as on the benefit side, or management will do it for you. The investment is more than the purchase: count the setup (adjusting templates, agreeing a folder structure), the team's learning time in hours, and a few hours of ongoing administration. Price internal hours at the same rate from finance, so the method stays consistent.
The payback time is then a simple division: the total first-year investment divided by the saving per month. Never present that number bare, but with a sensitivity check in three scenarios:
- cautious: only half of the measured saving proves achievable, for example because adoption lags;
- expected: the tally sheet is right and the full saving comes in;
- generous: tasks you did not count yet come along too, such as preparing packages for the shop floor.
If the proposal works even in the cautious scenario, within the timeframe your company normally applies to tooling, you have removed the biggest objection in advance. If even the expected scenario does not clear the bar, hold the proposal back yourself: the lower limits below which automating does not pay off yet are covered in When does automating pay off? Three thresholds.
The soft benefits: frame them as risk, not as an amount
Besides the hours there are benefits you cannot reliably express in money, but that management genuinely weighs. Less manual work means fewer wrong revisions heading to the shop floor, and anyone who has ever had a batch of sheet metal parts cut to an old revision knows how hard that kind of failure cost hits. Fixed, automated workflows shorten the ramp-up time of new colleagues, because the knowledge sits in the system instead of in heads. And engineers who fill their days with design work instead of export clicks stay longer, which counts in a tight labour market.
The trap is converting these items into amounts: then your whole case becomes attackable at its weakest point. Frame them as risks getting smaller: less chance of failure costs, less dependence on the one colleague who knows all the manual steps, less turnover. Risk language is management language; you do not need to attach a number to score the point.
The outline: seven lines for the meeting
Put the whole thing on a single page, in this order, and fill the blanks with your own figures:
- Trigger: one concrete situation, for example the rush order where two evenings went into export work.
- Measurement: this many hours per week on those tasks, tallied over two weeks, by the whole team.
- Translation: hours times the rate from finance, on a yearly basis, with the source named.
- Investment: purchase, setup and learning time, in the same method.
- Payback time: the expected scenario and the cautious scenario.
- Soft benefits: two sentences, phrased as risk reduction.
- Proposal: a bounded trial with an agreed measurement and a decision moment afterwards.
In the meeting, ask for a decision on the trial, not on the final purchase. That lowers the threshold for a yes, and the final decision follows naturally once the trial figures confirm the tally sheet. Close by asking who will help judge the trial results: whoever judges along is no longer an opponent at purchase time.
Frequently asked questions
Which hourly rate should I use in the calculation?
The fully loaded internal rate your finance department uses, overhead included. If you cannot get hold of it, present your case entirely in hours and explicitly leave the translation into money to management; that is a strong position too, because the measurement itself stands.
What if management does not believe my measurement?
Make the tallying visible instead of debating it: hang the sheet next to the department and invite the sceptic to watch a morning of exporting a drawing package. If needed, start with one task instead of the whole list; a small, undeniable measurement works better than a big one under dispute.
How do I propose a trial without asking for budget right away?
Pick a solution with a free trial month and agree in advance what you will measure and who judges the result. You can try Thundercad free for 30 days; the measurement you do in that month becomes the core of your final business case.