Neil Kelly Company

Jeremy Wood

Business Technology Modernizer

Jeremy Wood is Neil Kelly Company’s CIO, a pragmatic leader who built an AI orchestration layer connecting core business systems. He emphasizes pipelines over autonomy, trust engineering and iterative collaboration, making AI operational across finance, sales, marketing and production.

My objective is simple. I want to get useful information to someone when they can still act on it. Traditional reporting puts a dashboard or spreadsheet in front of someone and expects that person to find what matters. I would rather have the relevant information show up when a decision is due.

That is how I approach AI at Neil Kelly, a 78-year-old remodeling company. We have a small in-house IT function and no AI or data science team, yet roughly 30 AI-enabled workflows support functions across finance, sales, marketing and production.

Being a mid-market company has advantages. Large companies have more resources, but often have more system owners, approval processes, security requirements and competing priorities. At Neil Kelly, we can connect systems, test an idea and move it into production relatively quickly.

Nothing off the shelf connected the mix of cloud and on-premise systems we use, so I built a layer connecting Salesforce, Sage Intacct, SQL Server, Microsoft 365 services, JobTread, and Egnyte file storage. Our AI workflows run through it.

The separation is intentional. Models will continue changing, improving and becoming more accessible. I do not want our operating knowledge tied to a single model. Our data, process rules, knowledge and controls need to remain ours.

Discover Before You Automate

In early 2026, I settled on an order of operations. Connect the systems, understand what is happening, document it, automate what makes sense and monitor the result.

Salesforce showed why this matters. Multiple integrators, administrators and engineers had worked on the system over the years, leaving us without a reliable map of everything running in production.

We found 162 active automations and cataloged 147 flows. We also found four production bugs that nobody was actively looking for. In several places, the system behaved differently from our written procedures.

The documentation gave me an as-built picture of how parts of the company operated and a list of things to fix.

That work also changed how I use AI. Coding remains useful, but some of the best returns have come from investigating the business.

One analysis identified a six-figure annual software expense that had gone largely unquestioned for three years. We built a working alternative.

A data enrichment project taught a different lesson. We had started with an assumption that had not been tested carefully enough. Better AI could not compensate for a bad premise, but it discovered it much sooner, which allowed us to fail fast.

For technology leaders looking for a first project, I would start with a system already under their control. A service desk is a good example. Rather than asking AI only to close tickets faster, find out why the tickets occur, which problems repeat and which systematic changes could eliminate work.

From Analysis to Results

A finding matters when it saves work or helps someone make a better decision. Our weekly consultant brief prepares individual pipeline reviews for 30 salespeople across four offices, eliminating manual report preparation.

I also analyzed several years of opportunity history to understand how long sales typically spend at each stage. Every open opportunity is now scored weekly against the historical timing for its stage, helping salespeople find deals that are losing momentum.

We moved into finance with sales commissions. Errors there affect people’s pay, so the work had to be right. We both helped the people doing the work to be faster and more accurate.

From there, we moved into accounts payable. Each week, the system checks vendor emails against the ledger and helps the AP team prioritize millions of dollars in payments across hundreds of vendors. It also flags potential lien exposure. Statement reconciliation has caught invoices missing from the accounting system. Corporatecard transactions are matched against receipts and accounting records twice a week, replacing manual work.

We also went back through information accumulated over decades. More than 450 scope-of-work documents, including scanned records, were processed for about three cents each and turned into an estimating reference library. About 400 completed projects covering 20 years now support the cost calculator on neilkelly.com, giving prospective customers pricing information earlier.

Where AI Stops and Code Takes Over

The closer a system gets to payroll, billing or lien exposure, the less tolerance I have for unpredictable behavior.

We call many of these systems agents, although some are conventional data pipelines with AI handling only part of the job. That distinction matters.

When a manager receives financial figures, the model does not calculate them. SQL does. The model receives the finished numbers and, when useful, turns them into readable language. Rules that must always be followed are enforced in code rather than left to a prompt.

Technical accuracy does not guarantee adoption. Managers rejected AI-generated commentary in one report, so we removed it. They wanted the numbers, not an AI interpretation.

Our AP team responded differently. After testing an early reconciliation system, they suggested six changes. We made them, and version three became the one they preferred.

Each night, a monitoring agent (Agent Chief of Staff) also reviews production logs and sends a health report showing failures and unusual behavior.

Keep Experiments Separate From Production

I want employees experimenting with AI, especially people who understand the work and can spot opportunities IT may miss. But an experiment is not production software.

When an experiment proves useful repeatedly, we move or rebuild it in our production environment, where it gets testing, coded controls, monitoring and approval steps when required.

Some systems are now moving beyond providing information. In narrowly defined processes, they can prepare work for a person to review and approve. Weekly payment runs and contract turn-in packages are two examples.

The same infrastructure supports our production-platform migration. It handles nightly ERP job-cost synchronization, job creation and document routing. We are also mirroring roughly 4,900 customers and 6,000 contacts, with reconciliation to account for every record.

For technology leaders, I would start with information and systems the company already controls. Understand what is happening before automating it.

Models will keep changing. The durable asset is what we learn about how our company operates, including our data relationships, process rules, exceptions, controls and operating knowledge. I want those assets to remain independent of whichever model is best at the time.

We should own that part and rent the model.