The Most Useful AI Work Starts Before the Model

The most useful AI projects usually do not start with the model.

They start with the data that never quite makes it into the system.

That was the case on a recent private aviation project. The client had CRM data, outbound campaign data, website analytics, search data, and a market-data source for aircraft, operators, and aviation contacts. On paper, that sounds like plenty.

In practice, the data lived in separate places.

The CRM knew who the sales team had touched. The campaign system knew who opened, clicked, and replied. The website analytics knew which aircraft-service pages were getting traffic. The market-data platform knew which operators and aircraft existed in the addressable universe. But no single system could answer the operating questions the business actually cared about:

• Which aircraft operators are already in the CRM?
• Which ones have been emailed?
• Which ones engaged but never received sales follow-up?
• Which operators have aircraft types the company services?
• Which contacts are still phone-only?
• Which records are duplicates across systems?
• Which gaps should sales and marketing work next?

That is the real work behind AI.

Not the prompt. Not the demo. The plumbing.

The Spreadsheet Problem

The original path was familiar: download spreadsheets, clean them up, import them somewhere else, deduplicate the mess, and hope the next export did not break the workflow.

Spreadsheets are fine as a transfer mechanism when the work happens once. They are terrible as an operating layer.

Every manual export creates drift. Every manual import creates a chance for mismatched columns, stale data, duplicate people, inconsistent company names, and records that cannot be tied back to sales or marketing activity. A spreadsheet can move data, but it does not create a reliable system of record.

For an aviation sales motion, that matters.

Aircraft operators, owners, contacts, companies, aircraft types, airports, campaign engagement, CRM activity, and quote history all need to line up before the business can see the market clearly. If those objects stay trapped in exports, the sales team gets lists. If they are resolved into a lightweight Customer 360 data layer, the business gets intelligence.

Those are very different outcomes.

The Browser Workflow

The practical answer was a custom browser workflow.

The market-data source did not expose the relationships we needed through its API or exports: aircraft-to-operator links, contact-to-company mappings, and quote history were either unavailable or incomplete. Rather than rely on repeated spreadsheet downloads as the primary integration method, we built a Chrome extension that works from a logged-in, licensed browser session and captures the market-data records needed for downstream analysis.

The workflow operated inside a licensed, authenticated user session and collected only records the client was permitted to access. It preserved the existing sign-in and access-control boundaries while standardizing the downstream feed. The point was never to bypass access controls or automate credentials. The point was to reduce manual export work and create a more dependable path from permitted source data into the lightweight Customer 360 data layer.

From Records to Customer 360

The layer behind the project is a lightweight Customer 360 data layer built in Supabase.

It pulls together aviation market data, CRM records, campaign engagement, enrichment data, and website/search signals. The core job is identity resolution: mapping source records from different systems into canonical customer and prospect entities.

Identity resolution is what turns five partial versions of the same relationship into one usable operating view. It is what lets a team see that a contact exists in the CRM, received a campaign email, clicked on a maintenance page, is tied to a specific aircraft type, and has no logged follow-up.

That is the moment the data becomes actionable.

At the time of analysis, the layer linked roughly 49,000 source records into 35,000 canonical entities. Across 6,637 identified operators, it surfaced 2,205 that were already known but had not been emailed and 2,548 for which the business had only phone contact data. These categories do not overlap: an operator is either known-but-not-emailed or phone-only, not both.

That is not a dashboard vanity metric.

That is the difference between "we have a list" and "we understand our market coverage."

What Became Possible

Once the market data was flowing into the Customer 360 data layer, the business could ask better questions.

Not "how many contacts are in this spreadsheet?"

Better questions:

• Which aircraft types have strong campaign coverage?
• Which operators are already known but have not been emailed?
• Which campaign-engaged contacts have no CRM follow-up?
• Which contacts are phone-only and need enrichment, calling, or direct mail?
• Which operators are attached to aircraft types the service team actually supports?
• Which records need human review because the identity match is questionable?

The answers surfaced concrete operating gaps. In a companion piece, I explain how this foundation supported a daily sales-coaching workflow and changed the team's operating rhythm.

What the AI Layer Will Do Next

The AI layer is the next step, not the achievement described here. The achievement was creating an operating model reliable enough for AI to use without simply automating bad data.

The first model we plan to run against the layer is a prioritization scorer. It will take the resolved operator entities, combine aircraft-type fit, existing campaign engagement, CRM coverage, and contact quality into a single ranked view, and produce a weekly list of the highest-prospect operators with a short explanation for each score. The model's job is not to replace the salesperson; it is to make the next call list defensible and to surface operators the existing CRM view would miss.

That is where AI starts to matter.

AI is much more useful when it can reason over a real operating model. A model looking at disconnected spreadsheets can summarize chaos. A model connected to a resolved Customer 360 data layer can help prioritize action.

The Less Glamorous Lesson

The hard part was not making something sound intelligent.

The hard part was making the data dependable enough to trust.

That meant dealing with duplicate records, incomplete contact data, source-system mismatches, phone-only contacts, ambiguous company names, and records that needed human review. It meant building review queues instead of pretending every match was perfect. It meant accepting that not every useful metric is a revenue metric.

This is the part that gets lost in a lot of AI conversations.

Executives see the final answer and think the model did the work. Sometimes it did. But often the model is only useful because someone already did the unglamorous work of turning scattered systems into an operating layer.

That is what happened here.

The Chrome extension was not the product. The database was not the product. The AI was not the product.

The product was the operating view: a clearer understanding of the aviation market, who was already known, who had been contacted, who had engaged, and where the next move should be.

The Takeaway

If you want useful AI in a business, stop starting with the chatbot.

Start with the workflow.

Find the data that is stuck in spreadsheets. Find the manual export that happens every week. Find the system people trust but cannot integrate cleanly. Find the point where market knowledge fails to reach the people who need to act on it.

Then build the bridge.

Sometimes that bridge is an API integration. Sometimes it is a scheduled job. Sometimes it is a browser workflow. Sometimes it is a review queue. Sometimes it is all of the above.

The AI comes later.

And when it does, it has something real to work with.