Over the past month I wrote four posts about the use of AI in four very different businesses: a steel service centre, a professional services firm, a field service business, and a B2B distributor. On paper these businesses don’t have a lot in common: A steel service centre is manufacturing intensive, a law or accounting practice bills for judgment, a plumbing or HVAC company sells hours in a truck, and a distributor moves other people’s products. They have different customer bases, different economics, and a very different daily rhythm.

But as I looked at where AI could actually be put to effective use in each business, some patterns emerged. The same five patterns for where AI could be effective came up nearly every time, and so did the same short list of places where AI was the wrong tool. This post is all about these patterns, because I believe they are applicable to almost every business.

Pattern 1: Start with the overhead, not the craft

The most valuable first target for AI was almost never the thing the business sells. Instead, it was the coordination and overhead wrapped around it.

That might feel backwards to you, because the craft is where the expertise lives and it looks like the obvious place to focus your efforts. But the craft is also where the stakes and the judgment sit, and that makes it a place where a wrong answer is expensive. The overhead in a business is the opposite: it is repetitive, judgment-light, and largely non-billable, so any time saved there is close to pure gain.

The actual overhead in each business looked a bit different, but in essence, amounted to the same thing. In the professional services firm it was the non-billable hours (the intake, the knowledge lookup, the phone calls) rather than the billable work. In the field service business it was scheduling, the second trip back to the customer, and the paperwork rather than the diagnosis under the sink. In the distributor it was the prospect list nobody works and the order sitting in a shared inbox. These are the types of areas (the patterns to look for) where efficiency directly impacts the bottom line.

Pattern 2: Custom systems are best for custom logic

The second recurring pattern was that there are specific cases where building out custom systems is the best choice.

Off-the-shelf software is a good deal when your problem looks like everyone else’s. It stops being a good deal at the exact point where the value is in your own logic and your own systems: your pricing tiers, your scoping rules, your substitution lists, and the ERP, CRM, or scheduling system you already run. A generic tool cannot hold that logic, and it usually can’t reach into those systems in a way that matters.

The same type of build showed up in four forms. For a steel service centre, it was the RFQ-to-quote engine. For professional firms, it was the proposal and engagement-letter drafter, for field service the quote-from-the-truck, and for distribution firms the order and quote intake. On the surface they are different, but underneath, it’s the same pattern: a logic engine, not a document editor, that reads a request, applies the business’s own rules, and drafts an answer for a person to check and send. The pattern is industry-independent, but the logic inside it is not. That’s why these systems, which interact with your firm’s knowledge and expertise, need a custom build.

Pattern 3: Constrained retrieval over your own documents

If you want the lowest-risk place to start, the same pattern emerged for every industry: an assistant that gives authoritative answers based on your documents. This doesn’t need to be a custom build; there are ready-built systems available for this (including, of course, my own product, Docora).

A knowledge retrieval app like this has wide applicability. It can be added to your website to answer common customer questions (try it on https://archint.net), or used internally by departments such as HR or Operations to provide policy advice or work instructions. It can also be deployed in more specialized roles such as providing material specifications on the shop floor, the firm’s own precedent and matter files, the technician’s manuals and codes in the field, or catalogue and cross-reference guides at the distributor’s counter. In each case the appeal is the same: The scope is bounded, there is an audit trail, there is no open-ended liability because the system is not free-associating, and it is fast to stand up. This is the place I start many engagements, precisely because it can be implemented quickly, brings real results, and carries low risk.

Pattern 4: Keep a human on anything with legal, financial, or safety consequence

Every one of the four posts had a passage about where to stop, and they all drew the same line. When the stakes are high, AI does the prep work, but a person owns the decision of record.

Deciding where AI needs a human sign-off is industry-specific. In a professional firm, it’s anything where a licensed professional signs off. For a distributor it includes CASL: an outbound tool with nobody reviewing the list could result in you breaking the law, so a person must be involved. In field service it is anything to do with safety concerns; that must be routed to a human right away rather than dropped into a follow-up queue for an automated system to handle.

While the details are specific to each industry, there is a general principle here. Anything with legal, financial, or safety consequence needs a validation step and a person who owns the outcome, with no exceptions worth the risk.

Pattern 5: Fix the data and the process first

The last pattern is something that I repeat over and over again: AI pointed at a broken process or messy data does not fix anything. Rather, it just produces wrong answers faster and more confidently with less oversight.

The field service post demonstrated a good example of this. The challenge with automating processes there is not that you need more data, but rather that you need your existing data (e.g., free-form or handwritten notes) in a format that can be queried. In cases like this, an AI implementation needs to start with ensuring that your raw data is captured in a way that the system can use it. Jumping straight into AI-integrated automations is not the right thing to do.

The discovery process

In all four industries I covered in this series, the same five patterns emerged: point at the overhead not the craft, build where your logic and systems live, start with constrained retrieval, keep a human on the consequential decisions, and fix the data and the process before you point anything at them.

I can’t tell you from the outside which of these five fit your business, or in what order you should tackle them, or whether one of them is the whole opportunity and the other four are noise for you. That requires a discovery process (my “Discovery Day” engagement) where we jointly look at your business. But if you want to start this process yourself, you now have five patterns to look for with a test for each: does this actually need AI, is the underlying data clean enough to trust, and who owns the decision when it matters? Bring those three questions to any AI idea in your business and you will filter out most of the weak ones before they cost you anything.

If you want a hand doing that filtering against your own operation, that’s the conversation I have every week.

This post is part of a series on the current state of AI, focused on how it can be applied in practical ways to deliver measurable improvements in productivity, cost savings, and response times. If you’d like to explore more, all previous posts are available here under “Insights”; please read them and reach out with any questions or comments you have.