AI Feature Opportunities by Industry, and the Data Each One Needs

An AI feature is only as good as the data underneath it

Most AI features are simple to describe. Tell me which job is losing money. Tell me which claim is going to blow up. Tell me what this technician will need on the truck tomorrow. None of that is exotic, and none of it requires a research team.

What it does require is a clean answer to a boring question: what does one row of your data actually represent, and does every system agree on it?

That is where the money goes. A feature gets bought, the pilot looks good on a clean sample, and then it meets the real data. The same customer exists three times under three spellings. The budget field was overwritten every time a change order landed. Half the reason codes say "other." The feature does not fail loudly. It quietly returns numbers that are wrong in a way nobody can prove, and it gets abandoned six months later.

The gap is almost always findable before the spend, not after. The nine pages below set out concrete AI features by industry, and for each one, the specific data it needs, the gap that usually kills it, and how much of that data a company in that industry usually already has.

How to read each feature

Every feature on the nine pages below is written the same way: what it does, who acts on it, what it runs on, why it usually fails, and how ready the data usually is.

• One row per. The single most important sentence in any data project. Before anything else, say out loud what one record represents: one time entry, one claim line, one truck stop. If different people answer that question differently, nothing downstream can be trusted. The technical name for this is the grain.
• Described by. The things you want to slice the number by: customer, employee, job, part, location, date. If you cannot slice by it, you cannot manage by it.
• Must agree across systems. The handful of those descriptors that have to mean exactly the same thing in every system that touches them. If "customer" means something different in the CRM than in billing, every per-customer number is fiction. These shared definitions are called conformed dimensions, and they are usually the real project.
• History. Whether the feature needs to know what things looked like at the time, or whether today's picture is enough. Keeping the old version of a record instead of overwriting it is what data people call slowly changing dimension tracking (Type 2). Some features are useless without it.
• Data readiness. A rough call on how much of the data a company in that industry usually already has: already there, needs work, or needs building. It is about the industry, not about you, and the only way to know which one is true of your organization is to run the three steps at the bottom of this page.

Three steps to find out where you stand

1. Pick one feature and name the decision it changes. Not "we want AI." One feature, one decision, one person who would make that decision differently on Monday morning because of it. If nobody's behavior changes, the feature has no value no matter how well it works.

2. Say out loud what one row is. Write the sentence: "one row per ___." One time entry. One claim line. One pick. Then list every system that holds those rows. If two people in the room write a different sentence, that gap is the project, and it is cheaper to find it now.

3. Check whether the important words mean one thing. Take the three or four descriptors the feature depends on: customer, job, part, site, provider, asset. Pull the list from each system that holds them and compare. Where the lists disagree, you have found the work that has to happen first, and you have found it before spending anything on the feature itself.

Those three steps take days, not months, and they are the difference between buying a feature that works and buying one that returns numbers nobody trusts.