Three Things 500 Service Leaders Said Out Loud in Chicago. And One Thing Nobody Said.
This year I did two things at the Service Council Executive Symposium for the first time, at the same time.
I sat on the Service Council™ advisory board. And Ascendo AI sponsored.
Those are very different seats.
On the advisory board, you discuss about what keeps service leaders up in the night. As a sponsor, you find out in about one minute whether you got it right. There is no gentler way to audit your own assumptions than to stand in a booth for three days while 500 executives walk past and tell you what they actually came for.
A word on why this symposium is different. Fifteen years in, the Service Council still protects a roughly four-to-one ratio of practitioners to sponsors. That ratio is the entire product. It is why the hallway conversations are honest, why nobody performs, and why a VP of Global Service will tell you at 9pm what she would never say from a stage.
Here is what I kept hearing.
1. "We're building it ourselves." Then, quieter: "…in about six different places."
Build versus buy was supposed to be a settled debate by now. It is not. The debate has moved, and most of the coverage hasn't caught up.
Almost nobody in Chicago was asking should we build AI capability in-house. They have already started. They have a data science team, or a digital team, or an innovation function, and it has shipped something.
The question underneath was harder and more uncomfortable: why do we have four of these and none of them talk to each other?
One leader described a triage assistant built by the support org, a parts-forecasting model built by supply chain, a knowledge search tool built by the digital team, and a scheduling optimizer built by field ops. Four real proof of concept projects. Four real budgets. Four separate ingestions of overlapping data.
Zero shared memory between them.
That is not a build-versus-buy problem. That is a silo problem wearing a build-versus-buy costume.
And it produces a specific, predictable pain: every new use case starts from zero. The fifth project costs as much as the first, because nothing from the first four compounds. Meanwhile the list of use cases is not getting shorter. Triage. Dispatch. Entitlement. Warranty. Parts. Quoting. Onboarding. Escalation. Returns. A service organization has dozens of them, and building them one at a time, in isolation, is a ten-year roadmap dressed up as a two-year one.
This is where the honest case for a vendor lives - and it is not the case most vendors make. It isn't "don't build." It's time to market across the portfolio. You will never out-hire the use case backlog. The teams making real progress stopped asking build or buy and started asking what has to be common underneath, so the twelfth use case costs a tenth of the first?
Which leads directly to the part almost nobody had an answer for. Every one of those four projects reads documents, records and data. Not one of them captures judgment - the reasoning an expert engineer / technician applies when the documentation is wrong, incomplete, or silent. Four systems, all fluent, none wise.
2. "We're not ready. Our data isn't clean."
I heard some version of this sentence more than any other, and it is the one I most want service leaders to stop saying.
It comes out as a readiness checklist. We need to document who is skilled in what. We need to finish the skills matrix. We need to clean the knowledge base. We need to consolidate the systems first. We need the CMMS data to be trustworthy before we point anything at it. Then we'll be ready for AI.
I understand the instinct completely. It is the same discipline that makes great service organizations great - preventive maintenance before failure, documentation before escalation, training before confusion. Do the foundational work first.
But applied here, it becomes a permission slip that never arrives.
Because the data will never be clean. Field notes are written at 2am in a parking lot. Manuals contradict each other across product generations. The skills matrix is out of date the week after it's built, and the thing it can't capture is the only thing that matters - not that someone is certified on a platform, but that she is the one person who knows the failure mode that only appears in high humidity.
Here is the reframe I offered in every conversation I had, and it landed every time:
Readiness is an output, not a prerequisite.
The messy data is the asset. Twenty years of tickets where a Level 3 engineer explained the real root cause in one sentence and closed the case. Machine logs. Field service bulletins. Email threads. Photos. That corpus contains the operating judgment of your entire organization - and it is worth almost nothing today only because nothing can reason over it.
You don't earn the right to use it by cleaning it first. You start reasoning over it, and cleanliness becomes a byproduct of use. Every use case you automate should leave the organization more documented than it found it - including the skills question. Who is actually an expert at what stops being a survey you send out annually, and starts being something the system observes from the work.
If a system needs your data to be perfect before it can help, it was never going to help.
3. "I can't hire fast enough, and I can't keep the ones I have."
The talent conversation in Chicago was the most emotional one, and the most strategically revealing.
Hiring, Retention, Growth. Every leader named all three. But listening closely, they split into two groups that were having completely different conversations while using the same words.
One group was talking about talent as a cost problem. How do we cover the same territory with fewer people? How do we reduce onboarding spend? How do we absorb the retirements without backfilling?
The other group was talking about talent as a growth problem. We have signed more service contracts than we can staff. We are entering two new regions next year. Our install base grew faster than our bench. We need capacity, and we need it to be good capacity, fast.
Same symptom. Opposite strategy. And the second group was, without exception, the more interesting room to be in.
Because once you frame it as growth, the questions get much more precise. Not how do we hire fewer people but: how do we tell in an interview whether this person will actually be good at this specific work? How do we see a retention risk three months out instead of on the day the resignation lands? How do we cut onboarding from nine months to three weeks without lowering the bar? How do we get a second-year engineer to the answer a twenty-year engineer would have given - in the moment, on site, not in a training module next quarter?
Those are answerable questions. They are just not answerable by an HR system, because none of them are really HR questions. They are all the same question: can we see, capture, and transfer judgment?
The thing nobody said
Three themes. Three different rooms, three different sets of executives, three different vocabularies.
They are the same problem.
The silo problem is a judgment problem - four systems that each rebuild context from scratch because none of them share a memory. The readiness problem is a judgment problem - waiting to document what people know instead of capturing how they decide. The talent problem is a judgment problem - the expertise walking out the door is not knowledge, it is reasoning.
Nobody on any stage connected those three. I don't think that's an oversight. I think it's because the connective tissue doesn't have a name in most organizations yet, and things without names are hard to put on a slide.
We call it a Company Brain - institutional memory that reasons over everything your organization has already done, including the judgment nobody wrote down, and that every agent and every person draws from the same source. Not a knowledge base, which stores what someone wrote and waits to be searched. A reasoning layer over how your operation actually works.
Foundation models know the world. A Company Brain knows your business. Enterprise judgment is the combination of both - and it is the foundation all three of the Chicago conversations were circling without landing on.
→ See how the NeoCortex Company Brain works
What I'm taking home
The advisory board seat taught me which questions the industry is ready to ask. The sponsor booth taught me which answers it is ready to hear. They were not the same list, and the gap between them is the most useful thing I brought back from Chicago.
Thank you to Matt Wong, Stephanie Barrientez, Amit I., Timothy Krall, Shrinaath Chidambaram, Matthew Tice, Matthew Boyd, Ruud Geelen, Marc Coleman, Gary McCann, Kristen Weaver, Libby Healy, Mike Hughes, Michael Galon, Nick Cribb, Gyner Ozgul, Bret Allinson, Harold Heald, Sanjay Mujoo, Jackie (Counts) Rivard, Cynthia Patterson, Lisa Montoya McFarland, Chad Tearman, Genta Itoh, Cindy Steffen, Colin Gabhart, Ben Pryor, Michael Jessee, Wayne Fowler, Laura Hagen, Peter Seward, Malvin Naicker, Emrah Ercan, Mike Rembelski, Greg Parker, Monique McGlinch, Brad Haeberle, Gustavo Paredes, Andrew Scherbauer, Brandon Barton, Laura Mather, Ahmad (Amed) Moshiri, John Carroll, Gerardo Pelayo, the Service Council team, advisory board members, customers, and all the leaders I met for three days for the direct conversations.
Service leaders: of the three -
- building in silos
- waiting on data readiness, or
- the talent squeeze
which one is actually costing you the most this quarter?
I suspect most of us would answer that differently in private than we would on a panel.
References
- Beyond Break-Fix Field Service newsletter
- After AAMI - Karpagam Narayanan
- Your Best Technician Is Worth More Than Spirit Airlines' Entire Data Estate
- Syncron - What the Smarter Services Executive Symposium Revealed
- Neuron7 - Highlights from Service Council Executive Symposium
- Service Council - 2026 Smarter Services Executive Symposium
- Ascendo AI - NeoCortex: The Company Brain
Originally published on LinkedIn by Karpagam (Kay) Narayanan, CEO of Ascendo AI.
