AI Use Cases in Manufacturing

This page covers the other side of the business. The commercial, operational, and data-platform AI that runs on top of an ERP, a CRM, a phone system, an e-commerce storefront, a marketplace feed, and a meeting transcription stack. Call it the data-rich, sensor-light side. The work that decides whether customer service, sales, operations, quality, and supply chain can agree on a single number from a single source of truth.

The 10 use cases below are implementations FlowCo has shipped. Each one runs on data that already exists in the systems a discrete manufacturer is paying for. None require cameras, vibration sensors, or a new MES rollout. IBM's overview of AI in manufacturing names data quality as the foundation but treats it as one section near the end. This page makes it the through-line. For readers earlier in the journey, our AI for manufacturing plain-English guide walks the category from the top down before going implementation-deep.

Unified data warehouse across ERP, CRM, phone, web, and marketplace

What ships. A multi-channel manufacturer selling through dealers, direct web, and Amazon ingests seven systems into one Postgres warehouse. ERP for orders and invoices. CRM for contacts and deals. Phone system for calls. Corporate cards for spend. Meeting transcription service for action items. Direct web storefront for orders. Amazon Seller Central for marketplace settlement. Raw tables are append-only. Reconciled tables are written through an approval gate.

Data it touches. Acumatica, NetSuite, SAP, or Epicor on the ERP side. HubSpot or Salesforce on the CRM side. RingCentral on the phone side. Ramp or Brex on the spend side. Fireflies or Otter on the meetings side. Shopify, Magento, or a custom storefront for direct web. Amazon SP-API for marketplace. Single Postgres warehouse at the center.

What breaks it. Identity rules. If the customer master in CRM uses "Acme Lighting LLC," the ERP uses "Acme Lighting," and the support inbox uses "acme-lighting" with no shared dealer ID, the warehouse will join nothing. Master-data deduplication is Phase 0 work, not a stretch goal. Without it, the unified view reports two different revenue numbers for the same dealer and the team loses trust by Friday.

Cross-system data-quality and exception flagging

What ships. Audit-rule engines scan transactional data for breaks. Closed-won deals in CRM missing an SO# in ERP. Deals with invalid SO# values. Duplicate vendor records. Customer records that don't match across CRM and ERP. Time-and-attendance feeds that disagree by 15 minutes per person. Flags land in a severity-ranked data-quality table. Ops decides what gets fixed first. A 12-rule audit on a real corporate-card feed produced thousands of flags on its first production run.

Data it touches. ERP transactional records. CRM deal pipeline. Corporate-card transactions. Time-and-attendance feeds. Supplier master. Customer master. The same warehouse that powers every other use case on this page.

What breaks it. False-positive fatigue. A rule that flags one thousand records on its first run with no severity ranking burns out data stewards in a week. The fix is severity tiers plus a feedback loop. When ops marks a flag as "not a real issue," the engine learns. The rule that produced ten thousand low-severity flags gets retuned. The rule that surfaces one critical missed PO per week stays.

Role-scoped analyst access with Postgres roles and row-level security

What ships. A dedicated `analyst_readonly` Postgres role with 25 explicit SELECT grants on in-scope tables. Explicit default-DENY on sensitive tables. Row-level security policies on 14 tables. The same role is used by the human data analyst through a SQL editor and by an LLM-powered analyst chat through `SET LOCAL ROLE` per query. Defense in depth.

Data it touches. Every in-scope table the analyst is allowed to query. Nothing else. Tables flagged as sensitive are structurally unreachable, not policy-restricted alone.

What breaks it. Connection-pool state leakage. If session-local role settings leak across pooled connections, a different request can inherit the analyst's elevated context. The fix is transaction-scoped privilege via `SET LOCAL ROLE` plus a clean session reset before the connection returns to the pool. The 2024-2026 industry guidance is consistent on this: "AI never gets a standing broad role" is the canonical framing.

Real-time team dashboards by department and rep, with audit traceability

What ships. Pre-computed JSON blobs in a `dashboard_cache` table refreshed after every ERP sync. KPI formulas live in a versioned formula catalog. A sales audit trace tile so leaders can ask "where did $X come from" and see a row count plus result. 18 reps across 3 departments today on the sales side. The pattern extends to operations dashboards on the same warehouse with no new infrastructure.

Data it touches. ERP order data joined to a sales-team config that names exclusions: known bad SOs, marketplace double-counts where ERP AR books marketplace sales to a non-marketplace rep, and similar wiring issues. Direct web orders. Marketplace orders. The unified warehouse joins them.

What breaks it. KPI formulas that nobody can audit. If a Friday meeting opens with "the dashboard says $480K but my tab says $510K," the page is dead by Monday. The fix is the audit trace tile. Click the KPI, see the rows. The pattern that makes a dashboard survive the second meeting.

Daily executive HTML email reports with AI insights

What ships. A daily 9 a.m. inbox arrival summarizing yesterday's numbers. Sales side covers YTD by pipeline, per-rep leaderboard, closed-won in the last 7 days, and open pipeline. Phone side covers call volume, missed calls, per-rep activity, silent reps, and peak hour. ERP side covers shipped orders, invoices, AR aging. Each report includes a Claude-generated AI insights section that names the day's notable patterns plus an audit-trace link if a number looks wrong.

Data it touches. Same warehouse as the dashboards above. Pure SELECT. The reports don't write to anything. They render HTML and send via a transactional email provider.

What breaks it. Email delivery. If the report cannot reach more than the founder's mailbox because the sender domain isn't verified, the broader team never sees it and the pattern stays in pilot. Domain verification on the email provider is a Phase 0 task hiding inside what looks like a Phase 1 deliverable. Trust is operational, not technical.

Multi-channel revenue reconciliation across direct, dealer, and marketplace

What ships. Two reconciliation jobs. One compares YTD and monthly revenue between the direct web storefront and the ERP. It runs side by side with the team's existing tracking. It includes 15 random spot-check orders for manual review. The other runs weekly. It produces a digest of "missed money" candidates: ERP sales orders without a matching direct-web record. The digital team manually reviews them on Friday. The pattern is named in industry research as "owner-attribution reconciliation" and "channel-leakage detection".

Data it touches. ERP order header and line. Direct web storefront orders via the storefront's order API. Marketplace orders via SP-API. The unified warehouse joins them by SKU, customer, and date with an explicit policy for which channel owns the revenue when both claim it.

What breaks it. Owner-attribution mistakes. The pattern FlowCo caught on a recent intake: a non-marketplace rep was credited with the full Amazon channel because the ERP AR module booked every marketplace sale to that record. Their numbers were inflated by the entire marketplace and the rep responsible for Amazon showed $0. The fix is an explicit ownership policy plus exclusion rules. Industry research calls this out as "one of the biggest blind spots in AI revenue intelligence": the same economic event counted twice because dealer and direct web both claim it, the marketplace order is also recorded in CRM as a direct opportunity, or the channel partner and manufacturer both book the sale.

Corporate-spend audit and anomaly detection

What ships. A 12-rule audit engine that scans corporate-card transactions every day. Rules cover duplicate charges, recurring SaaS subscriptions without active users, vendor anomalies, miscategorized spend, off-hours spend in sensitive categories, and dollar-amount limits by role. Flags land in a severity-ranked data-quality table. A natural-language spend query engine lets finance ask "show me all corporate-card spend on subscriptions over $500 in Q4" without writing SQL.

Data it touches. Corporate-card transactions, merchants, and audit logs. The vendor master from ERP. Employee and role data from the HR system. The unified warehouse joins them.

What breaks it. Vendor master mess. If the corporate-card platform calls one vendor "GOOGLE*SERVICES 1234" and the ERP calls it "Google LLC" and the buyer's spreadsheet calls it "Google Workspace," the SaaS-waste rule produces three separate vendor records for the same legal entity and the de-duplication rule never fires. The fix is a normalized vendor master plus ongoing reconciliation. Industry research reports 5 to 10% reduction in SaaS spend in year 1 and 20 to 40% reduction in month-end close time on this pattern. The SaaS-waste numbers depend heavily on the vendor-master cleanup that no marketing copy mentions.

AI analyst chat for natural-language Q&A on operational data

What ships. An LLM-powered chat that turns operator questions into SQL against the warehouse. The system prompt encodes in-scope schema and KPI rules. The model produces SQL. A SQL lint engine validates it. The query runs under `SET LOCAL ROLE analyst_readonly`. The result returns to the user with the audit trace. Every Q&A turn is logged with the prompt, the generated SQL, the row count, the answer, the outcome, and token usage. Rate-limited at 50 questions per day per analyst.

Data it touches. The warehouse. The same in-scope tables the human analyst can read. Nothing else. Defense in depth: SQL lint plus role-based access plus row-level security plus audit logging.

What breaks it. Trusting the SQL lint alone. A lint engine that catches 11 of 12 attack patterns and lets the 12th through is an open door. The fix is layered defense. Lint catches obvious things. The role enforces what the lint missed. RLS catches what the role missed. The audit log catches what RLS missed. Industry guidance frames this as "denial-of-wallet attacks": rate limits and query-cost caps are security controls, not cost controls alone.

Approval-gated AI with recommend-versus-execute boundary

What ships. Every proposed write to the unified data layer routes through an approval engine. The agent builds a structured proposal: target entity, before-and-after values, reasoning, confidence, risk class, and the role required to approve. That proposal lands in an `agent_proposals` audit table and prints the canonical block. The admin types yes, no, or modify. On no, the rejection becomes a permanent correction the agent reads on the next run so it does not repeat the mistake.

Data it touches. The unified data layer. Raw append-only writes skip the gate. Reconciliation writes do not. The audit trail of every proposal, decision, and reason lives in two append-only tables plus a file-based correction log.

What breaks it. Approval fatigue. If every routine reconciliation generates a stop-and-wait prompt, the human approver auto-approves everything by week 2. The fix is risk classification. Low-risk reversible writes execute directly with logging. Medium-risk writes route through approval. High-risk irreversible writes require manual re-keying through a privileged tool. The pattern FlowCo ships matches the NIST AI Risk Management Framework Govern and Manage functions, ISO/IEC 42001:2023 AI Management System governance, and the EU AI Act Articles 14 and 26 on human oversight for high-risk systems.

Phone-call and meeting summaries tied to CRM and ERP context

What ships. Two pipelines feed the warehouse. The first downloads phone-system recordings, runs them through OpenAI Whisper for transcription, and writes structured call records with participants, duration, and the transcript. The second pulls meeting transcripts and action items from a meeting-transcription service via GraphQL and writes structured meeting, attendee, and action-item rows. Both pipelines run an allowlist check before transcription so the system never spends API credits on non-approved audio.

Data it touches. Phone-system call logs. Recording audio files. Meeting transcripts. Action items. Joined to the CRM record for the customer, the ERP order they referenced, and the deal they affect.

What breaks it. Transcription cost. A 200-person manufacturer recording every internal meeting and every customer call burns through a four-figure monthly Whisper bill in a week. The fix is the allowlist plus per-call caps: 20-minute duration, 24-megabyte file, 50 calls per run. AssemblyAI's 2024-2026 overview notes you still need an orchestration layer to push transcription outputs into CRM/ERP, classify intents, and manage retention. The Mutiny 2026 buyer's guide puts it directly: "transcription quotas and allowlists are how finance teams keep the category from turning into an uncontrolled SaaS tax."

1. 01

   Quality and traceability. Vision-based defect detection, CAPA workflow, recall traceability through serial-number trees. Vision and quality-management vendors specialize here.

2. 02

   Capacity planning and finite-capacity scheduling. Advanced planning and scheduling vendors with constraint solvers and shop-floor MES integrations specialize here.

3. 03

   Dispatching and MES-driven shop-floor control. MES platforms own this layer.

4. 04

   Predictive maintenance. Sensor, vibration, and vision-driven equipment failure prediction. Equipment-OEM platforms and CMMS-specialist vendors do this work.

5. 05

   Generative design and digital twins. Engineering simulation vendors own this.

6. 06

   Computer-vision-based manufacturing AI. Vision vendors do this better.

FlowCo focuses on the commercial, operational, and data-platform side of AI for discrete manufacturers. Different specialties solve different problems. If the use cases above are what brought a reader to this page, IBM's overview of AI in manufacturing and SAP's AI in manufacturing guide are neutral starting points for that side of the market. For the buyer-side decision of whether to buy a sensor or MES platform, build in-house, or layer on an existing ERP, see Manufacturing AI Software: Buy, Build, or Layer?. For the full vendor landscape across enterprise, MES, ERP-native, data-platform, and consultancy lanes, see AI manufacturing companies.

An integrator on LinkedIn put it bluntly: "Most of what I see focuses on optimizing individual processes inside a factory: predictive maintenance, process monitoring, quality control." The page above this section picks a different focus on purpose. The work other vendors specialize in is still work that needs doing.

1. 01

   One unified Postgres warehouse. Not five BI tools pointed at five databases. Every use case reads from the same set of tables.

2. 02

   Append-only raw layer plus reconciled unified layer. Source systems write to immutable raw tables. Reconciliation produces a unified layer with full identity-rule documentation.

3. 03

   Approval-gated writes. Anything that changes the unified source of truth or a reconciliation rule routes through a human. The audit trail captures every proposal, approval, and rejection.

4. 04

   Audit traces from every dashboard number back to source rows. Trust survives the Friday meeting because the team can click the number and see the records.

5. 05

   Recommend-versus-execute boundary. AI proposes. Human approves. The system writes. Same governance discipline NIST AI RMF, ISO 42001, and the EU AI Act all recommend for high-risk enterprise AI.

The model is the easy part. The discipline that makes the model survive a finance review, an internal audit, and an operator's Monday-morning skepticism is the work. Any ai in manufacturing case study FlowCo can share, anonymized, follows these same five patterns.