AI for manufacturing

Patterns, no client yet

The floor is instrumented. The office is not.

Instrument makers, industrial equipment builders, and manufacturers whose back office never got the same attention as the line.

Manufacturers have spent decades measuring the production line. The office around it never got that treatment: quotes assembled by hand, tribal knowledge in one engineer's head, and a service call answered from memory. That gap is where the administrative work still waits.

No client yet

We have not built for a manufacturer

The office

Not the line, not the machines

Start here

A workshop, not a pitch

Where the time goes

You are losing time in predictable places.

We have not built a system for a manufacturer. We have spent real time in the life-sciences instrument category, learning how those businesses go to market. The patterns below are the office-side ones we would expect to find and would go looking for first.

The quote that needs an engineer

A configurable product means every quote is a small engineering exercise: what is compatible, what the lead time is, and what this configuration actually costs. So quoting routes to the one person who knows, and the sales cycle is bounded by their calendar.

Quoting waits on one engineer

The knowledge in one head

Why this tolerance, why that supplier, what happened the last time somebody tried the cheaper part. It is decades of accumulated judgment and it is written down nowhere. It retires when they do.

Decades of judgment, unwritten

The service call answered from memory

A customer calls about a machine in the field. Answering well means knowing that unit's configuration, its history, and what usually causes this. That lives across a service log, an email thread, and a technician's recollection.

The unit's history is in three places

The documentation always three revisions behind

The product changed. The manual, the spec sheet, and the installation guide did not, because updating them is real work that competes with shipping. So the field runs on documents that describe last year's machine.

The docs describe last year's machine

The technical buyer nobody markets to

The person specifying your equipment is a working technical professional who searches for what they do in their own vocabulary, not yours. Most manufacturers in this category are genuinely weak at marketing, which is an opening if you are not.

Buyers search in their words, not yours

The RFP that eats a week

It arrives with two hundred questions, most of which you have answered before, in a document somebody has to find. A week of technical people assembling answers that already exist somewhere in the building.

Answers that exist, assembled again

The machine

Map the operation before pitching AI at it.

The office machine around the production line. The line itself is not on this page.

01

Get specified

  • A technical buyer looking for a solution in their own vocabulary, not your product's
  • Technical content, comparisons, and the documentation that decides whether you get on the list
  • The RFP, and the week of assembling answers you already have

02

Configure and quote

  • What is compatible with what, which is engineering knowledge in a sales conversation
  • Pricing, lead time, and the exceptions that make each quote a small project
  • The approval, which is another calendar the deal has to wait for

03

Build and ship

  • Production, which is instrumented and measured and not what this page is about
  • Supply chain exceptions, which are most of the actual work
  • Documentation and hand-off to the customer, which is always behind

04

Serve the installed base

  • Service calls answered from a log, an email thread, and somebody's memory
  • Parts, consumables, and the recurring revenue that depends on all of this working
  • What the field is teaching you about the product, which usually reaches nobody

The split

The system drafts. Your people decide.

The system handles

  • Drafting a configured quote from the compatibility rules, for an engineer to check instead of build
  • Capturing the tribal knowledge into something readable, from the people who hold it, while they are here
  • Assembling a service call's context: this unit, this configuration, this history, before the tech picks up
  • Drafting documentation updates when the product changes, for a person to review and publish
  • Answering the two hundred RFP questions from what the company already answered before
  • Reading what the field is reporting and telling you what the installed base is saying this quarter

Your team handles

  • Every engineering decision. Compatibility, tolerance, and anything with a safety implication
  • The final quote and the price. The system drafts, an engineer signs
  • Anything published as a specification, because the field will build against it
  • What is true about the product, which means approving what enters the knowledge base
  • The customer relationship, which in a capital-equipment sale is most of the sale

The line stays out of scope, and that is deliberate. The production floor has real-time control systems, safety interlocks, and vendors who specialize in them. We are not that, and a consultancy that offers to point a language model at your line should worry you. Everything on this page is the office: quoting, knowledge, service context, and documentation. That is the part nobody instrumented.

What we build

The systems, named.

01

Configure and quote drafting

The compatibility rules and the pricing logic written down once, so a quote gets drafted and an engineer checks it. The engineer's judgment stays in the loop. Their calendar stops being the sales cycle.

02

Tribal knowledge capture

The interviews that turn thirty years of why-we-do-it-this-way into something a new engineer can read. Not a wiki nobody writes in. A structured knowledge base built by asking the people who hold it, while they are still here to ask.

03

Service call context

Before the technician picks up: this unit, this configuration, this service history, and what usually causes what the customer is describing. Assembled from the systems that already hold it, instead of from three tabs and a memory.

04

Documentation that keeps up

The product changed, so the manual, the spec sheet, and the install guide get drafted forward for a person to review and publish. The field stops running on documents that describe last year's machine.

05

RFP response assembly

Two hundred questions, most of them answered before, drafted from the company's own prior answers with the sources attached. A week becomes a day of technical review, which is the part that actually needed the technical people.

06

The company brain for a manufacturer

Compatibility rules, pricing logic, product knowledge, and the field's accumulated experience, in your own cloud. Every system above reads from it, and none of them work without it.

Under the hood

Fits into the stack you already run.

Planning and ledger

NetSuiteSAPEpicor

Product data

SolidWorks PDMArena

Service and CRM

SalesforceServiceMax

Your planning system is the system of record and it stays there. To be direct about scope: we build in the office layer that reads these systems and writes back to them. We do not touch the production line, the control systems, or anything with a safety interlock, and you should be wary of a generalist consultancy that says otherwise.

Principles

How we think about AI inside manufacturing.

We have no manufacturing client, and no manufacturing numbers

We have spent real time in the life-sciences instrument category learning how those businesses go to market, and that is where this vocabulary comes from. It is not a build. Every number on this site belongs to a system we shipped, and the construction and insurance pages are where those are.

The office, never the line

The production floor is instrumented, controlled, and safety-critical, and it has specialists. The office around it is where the work still waits on one person's calendar and one engineer's memory. That is a real problem and it is the one we would be useful on.

Capture the knowledge while the person is still there

The most valuable asset in a lot of manufacturers is thirty years of accumulated judgment in a few heads, and the standard plan is to hope it transfers by osmosis before they retire. It does not. Writing it down is unglamorous, urgent, and almost always late.

Your buyer is technical and searches like one

The person specifying your equipment uses their working vocabulary, not your product naming. Manufacturers in this category are often genuinely weak at meeting them there, which is not a technology problem, but a system that knows your product deeply is how you fix it at scale.

Same approach, different language

The pattern shows up next door.

Questions

Answered plainly.

Do you have manufacturing clients?

No. We have spent real time in the life-sciences instrument category, learning that market and how those companies go to market, which is where the vocabulary on this page comes from. It is study, not a build. The construction and insurance pages have shipped systems with client names and real numbers.

Would you touch our production line?

No. The line has real-time control systems, safety interlocks, and vendors who specialize in exactly that, and we are not one of them. Everything on this page is the office: quoting, knowledge capture, service context, documentation, and RFP work. A generalist AI consultancy offering to point a model at your production floor should worry you.

Can AI handle configure-and-quote?

It can draft it, once the compatibility rules and pricing logic are written down, which is usually the actual project. The reason quoting takes a week is not that the quote is hard, it is that only one engineer knows what goes with what. Writing that down means an engineer reviews a draft rather than building one, and the sales cycle stops being bounded by their calendar. The engineer still signs.

How do you capture knowledge from engineers who are about to retire?

By interviewing them, structurally, and turning it into something readable. It is not a wiki you ask them to write, because they will not, and it is not a recording nobody listens to. It is a set of sessions that pull out the why, written into a knowledge base a new engineer can actually read. This is the least technical thing on the page and often the most valuable, and it has a deadline you do not control.

What about the RFPs that take a week?

Most of those two hundred questions have been answered before, somewhere in your building. A system that has your prior answers can draft the response with sources attached, so the technical people spend a day reviewing rather than a week retrieving. The review still has to happen, because your answers become commitments.

Where would you start?

A readiness workshop. One session, one real workflow mapped end to end, and you leave with the map and a dated plan whether or not you build anything with us. In a category where we have no case study, paying us to guess would be a bad trade for you.

Who owns what gets built?

You do, from day one. The code is in your repository, the knowledge base with your compatibility rules and your accumulated field experience is in your cloud, and the accounts are in your name. That knowledge base is arguably your most valuable asset, and a vendor should not be holding it.

Read next

The thinking behind it.

Where to start

Every one of these starts the same way.

Find the bottleneck, price the fix, build the system, then keep compounding it. The four engagements are how you buy it, and you can start on any rung.

See the four engagements →

Get started

Ready to see what's slowing you down?

Book a 30 minute call. We find the one place your work waits on you, and you get a straight answer about whether AI is the fix. No pitch, no deck.