The Mid-Sized Factory Playbook for Buying AI When You Cannot Buy People

Start with the vacancy report, not the model card.

A mid-sized manufacturer does not need an AI strategy broad enough to impress a conference. It needs a way to keep shipping when maintenance roles stay open, experienced supervisors retire, and one failed machine wipes out the week's margin. That pressure turns industrial automation from an optional efficiency project into a practical capacity decision.

The labour shortage is real, but the numbers need careful handling. The 2026 Smart Factory Outlook from IIoT World cites a need for roughly 425,000 additional US construction workers in 2026 and reports that 86% of employers see AI and collaborative robotics as major tools for change. Construction is not manufacturing, and an employer survey is not a purchase order. Still, both figures point to the constraint factory operators already recognise: hiring alone will not restore all the capacity they need.

That changes the buying question. Instead of asking whether AI might improve margin somewhere, ask which missed hire or recurring failure is already limiting output. The answer gives you a workflow, an owner, and a number against which to test the investment.

Buy one avoided failure first

Start with the two or three assets whose unplanned downtime costs the most. Write down the cost per hour, the usual failure modes, the warning data you already collect, and what the maintenance team would do with an earlier alert. If nobody can name the action that follows an alert, do not buy the prediction system yet.

Predictive maintenance is a sensible first workload because it targets an expensive, measurable event. The Discover in AI industrial transformation report describes a mid-sized precision manufacturer, OmniFab Solutions, cutting unscheduled downtime by as much as 25% after adopting AI-based predictive maintenance. Treat that as a reported case, not a guaranteed benchmark. The useful part is the shape of the result: fewer breakdown hours on named assets, measured against the previous operating baseline.

The snag sits between prediction and repair. A model can flag abnormal behaviour, but value only appears when someone reviews the alert, decides whether to intervene, schedules the work, and records what the technician found. Weak maintenance records make that loop harder. If work orders contain vague fault codes, missing causes, or inconsistent close-out notes, the first project may be data cleanup rather than machine learning.

Run the pilot on one asset class. Set a baseline for unplanned downtime, emergency call-outs, maintenance hours, and false alarms. Give one maintenance lead authority to tune alert thresholds and reject useless alerts. Review the results after a full maintenance cycle. Expand only if the system catches failures early enough to change the work plan without burying the team in noise.

The purchase should fit inside that operating loop. Sensors, data collection, model, alert, work order, technician decision, recorded outcome. A vendor that cannot show where its product enters and leaves that chain is selling a demonstration rather than a maintenance result.

Automate the queue before the job

Next, find the administrative queues that steal scarce hours from people you cannot replace easily. Invoice matching, supplier forms, inspection records, production reporting, and shift handovers are good candidates when the inputs repeat and exceptions can be sent to a named person.

The same Discover in AI report says OmniFab saved 15% to 20% in operational costs during its first year with robotic process automation. Again, use the figure as a case claim, not a forecast for your factory. Ask what was automated, which costs were included, how exceptions were handled, and whether the saving came from lower spending, higher throughput, or reassigned staff time. Those are different outcomes and should not share one ROI line.

Choose a queue with enough volume to matter and few enough variants to map. Measure how many items arrive, how long each takes, how often staff correct errors, and how long exceptions wait. Then automate the common path while routing uncertain cases to the existing owner. Do not begin with a process that crosses six systems, depends on unwritten judgement, and changes every week. That is an expensive way to discover that the process itself is the problem.

Keep the target practical. The system should remove repetitive handling so an experienced employee can spend more time on supplier problems, quality escapes, planning changes, or maintenance decisions. In a labour-constrained factory, the prize is usable capacity. A saved hour matters when it moves to work that is blocking shipments.

This is also how to avoid the proof-of-concept graveyard. The Econify analysis of AI and productivity describes AI as a general-purpose technology and points to predictive maintenance and demand forecasting as firm-level productivity tools. The big economic label is less useful to an operator than the mechanism beneath it. AI pays when it shortens a real queue, improves a recurring decision, or prevents a costly event. Every project should name one of those mechanisms before procurement starts.

Make the workforce plan part of the purchase

Assign an operator before signing the contract. Predictive maintenance needs someone who owns alert quality and the link to work orders. Administrative automation needs someone who owns exceptions and notices when a supplier, form, or business rule changes. Without those owners, the software will continue running while its usefulness decays.

Training belongs in the business case because the work itself is moving. The UK Government's AI labour market and skills projections project 2.5 million additional jobs between 2020 and 2035 in skilled white-collar occupations. The report expects growth in roles that create, specialise in, or implement AI, alongside declines in some administrative and skilled-trade occupations. It is a projection, not a promise, but it supports a sensible factory-level bet: more employees will be asked to configure, supervise, and improve automated systems.

Do not hide that work inside an already full job. Name the maintenance lead, process owner, or line supervisor who will spend time on it. Set aside hours for reviewing alerts, correcting classifications, documenting exceptions, and teaching colleagues. If the business case assumes the system improves itself without this work, the payback calculation is missing labour.

Take a one-page proposal to the board. Name the constrained workflow, its current cost, the owner, the first 90-day test, the stop condition, and the expansion condition. For predictive maintenance, the stop condition might be an alert rate the team cannot use or no measurable reduction in emergency downtime. For an administrative queue, it might be error rates above the manual baseline or exception handling that consumes the hours automation was meant to save.

Then pick the first asset or queue and price the current failure in pounds or dollars. That number is the budget boundary, the vendor filter, and the baseline for deciding whether the system earned a second deployment.