They Asked for a Chatbot. I Saw Something Bigger.
Leadership wanted "something AI." They got an intelligence platform that changed how the entire organization thinks about what's possible.
May 24, 2026
AI Strategy, Applied AI Design, Change Management, Agentic AI
The Ask
Leadership came to me with a request: build us a chatbot. That was the brief. No scoped requirements. No defined problem statement. No articulation of what business outcome the chatbot was supposed to produce or what operational friction it was supposed to relieve. Just a general directive that the organization needed "something AI" — because the market was moving, competitors were making noise, and the feeling was that we needed to be doing something too.
The ask wasn't wrong. The instinct to move toward AI was correct. But the execution concept — a chatbot — was the default answer of an organization that hadn't yet developed the frame of reference to know what else was possible.
The Actual Problem
Underneath the chatbot request sat a real operational problem that nobody had connected to the AI conversation.
Account managers across the $6B broker-dealer book of business were manually pulling information from 14 separate data sources to assemble a complete picture of their accounts. Client performance data lived in one system. Activity history lived in another. Product holdings, service cases, relationship mapping, revenue trends — all fragmented across disconnected platforms with no unified view.
The result: AMs spent significant portions of their week not managing relationships or driving business strategy, but stitching together information by hand. Fragmented reporting. Duplicated effort. Incomplete context when walking into client conversations. And executive leadership receiving synthesized account views that were only as current as the last time someone manually compiled them.
That's not a chatbot problem. That's a data architecture and intelligent synthesis problem. And the gap between those two things was where the real opportunity lived.
The Disconnect
Leadership didn't know what they didn't know. Their understanding of AI at that point was bounded by what they'd seen externally — conversational interfaces, chat-based assistants, Q&A bots layered on top of knowledge bases. That was the entire mental model. The concept of an AI-powered platform that could autonomously consolidate, analyze, and surface actionable intelligence from disparate data sources wasn't in their frame of reference yet.
The request for a chatbot wasn't a failure of imagination on their part. It was a perfectly logical request given the information available to them. My job was to expand that frame of reference — but I had to do it through demonstration, not explanation.
The Decision to Build Beyond the Ask
I took the chatbot request and immediately recognized that we could deliver something substantially more valuable. The 14 fragmented data sources the AM team was manually synthesizing represented an opportunity for an AI-analyzed, consolidated intelligence layer — not a conversational interface, but an analytical engine that did the synthesis work automatically and surfaced the results in a format that was immediately actionable.
The problem: that's not what I was asked to build. And when I initially pushed back on the chatbot concept and proposed something bigger, I was met with direct resistance. The feedback was explicit — stick to what was requested. Keep it simple. Build the chatbot.
Off-Hours Development
I made a decision. Rather than continuing to pitch an idea nobody could visualize, I would build it — on my own time, without authorization, and without the safety net of organizational backing.
Nights and weekends. I designed the data architecture within Salesforce — the custom objects, fields, relationships, and automation flows required to consolidate the 14 fragmented data sources into a single unified structure. I configured the Agentforce layer on top of that structure — building the AI-analyzed view that could take raw, multi-source data and produce synthesized account intelligence without manual intervention.
I tested it. I debugged it. I iterated through the edge cases where data from different source systems conflicted, where field mapping required interpretation, where the AI analysis needed guardrails to produce outputs that were genuinely useful rather than technically correct but operationally meaningless. Every iteration moved the prototype closer to something I could put in front of leadership and say: this is what I was trying to explain. Look at it.
The Platform Architecture
The Account Intelligence Platform consolidated the following into a single AI-analyzed view:
Client performance metrics across product lines
Historical activity and engagement data
Relationship hierarchy and coverage mapping
Revenue trends and growth trajectory analysis
Service case history and resolution patterns
Product holdings and allocation breakdowns
Competitive positioning indicators
Meeting cadence and relationship health signals
Each data point had previously required manual retrieval from a separate system, manual synthesis against the others, and manual interpretation before an AM could form a complete account picture. The platform did all of that autonomously — pulling from source systems, running analytical synthesis through the Agentforce AI layer, and surfacing a consolidated intelligence view that was current, comprehensive, and immediately actionable.
The Prototype Presentation
When the prototype was functional — not perfect, but functional enough to demonstrate the concept — I brought it to my direct leadership. No formal meeting request. No slide deck. No proposal document. Just: here, look at what this could be.
The reaction was immediate. They got it. The gap between "chatbot" and "intelligence platform" was no longer an abstract argument — it was visible on a screen, working with real data, producing real outputs. Within that single demonstration, the conversation shifted from "stick to the chatbot" to "how fast can we get this in front of the AM team?"
Stakeholder Alignment and Refinement
From that point, we moved into rapid iteration with the Account Management team. Demo sessions. Feedback collection. Requirements refinement based on what the actual end users said they needed versus what the design assumed they needed. Use case expansion as the team realized capabilities they hadn't thought to ask for.
Through the entire development and deployment cycle — discovery, design, stakeholder alignment, testing, refinement, deployment — the project was 100% owned and built by me. Sole product lead. Six months from initial concept to production deployment.
Adoption and Utilization
The platform went live and was adopted by account managers and executive staff across the full $6B broker-dealer book of business. Fourteen previously-manual data points consolidated into a single AI-analyzed view. The stitching-by-hand era ended.
Adoption wasn't mandated — it was organic. The platform was demonstrably faster, more comprehensive, and more current than anything the manual process could produce. Users adopted it because it made their jobs measurably better, not because someone told them to use it.
The Catalyst Effect
The bigger outcome wasn't the tool itself — it was what it did to the organization's understanding of what AI could be.
Before the Account Intelligence Platform, the executive mental model of AI was bounded by chatbots. After seeing what the platform actually delivered — autonomous data consolidation, intelligent synthesis, analytical surfacing — that boundary evaporated. Senior leaders stopped asking for basic conversational interfaces and started bringing real, complex, operationally significant use cases to the table.
The platform didn't just solve one team's data problem. It rewrote the organization's imagination about what was possible. It opened a pipeline of AI use cases across multiple business units that hadn't existed before — not because the ideas weren't there, but because nobody had a frame of reference for what AI could do beyond chat. One working prototype gave them that frame of reference.
Recognition
The work was recognized by direct leadership, the division director, and the sales director — not as a technology achievement, but as a strategic shift in how the organization approaches AI capability development. The distinction matters: this wasn't praised as a good build. It was praised as a fundamentally different way of thinking about where AI creates value.
Building Against the Grain
The most significant challenge wasn't technical — it was organizational. I was explicitly told to build a chatbot. I chose to build something else instead, on my own time, without approval. That decision could have gone very differently.
If the prototype had failed to impress — if the demo had fallen flat, if leadership hadn't immediately seen the value — I would have spent weeks of personal time building something that got shelved while still being expected to deliver the chatbot I'd been asked for. The risk was real. Going against a direct instruction, even with good intent, carries professional exposure in any organization. I was betting on my ability to make the proof so compelling that the initial resistance would become irrelevant.
That bet paid off. But I want to be honest: it was a bet. Not every unconventional approach gets validated. The lesson isn't "always ignore what you're told." The lesson is to know the difference between a situation where the ask is wrong and a situation where you just disagree with it — and to have enough conviction in your own assessment to accept the risk of being wrong.
The Scalability Question
The prototype I built proved the concept and drove adoption — but it was built by one person, on one person's timeline, with one person's architectural decisions. That creates a specific kind of technical debt: the system works, but it reflects the thinking and constraints of a solo builder rather than the requirements of an enterprise-scale platform.
Transitioning from "Trey's prototype" to "organizationally owned, maintained, and scalable platform" required a different set of conversations — ones about governance, ownership, maintenance responsibility, enhancement roadmaps, and what happens when the original builder isn't the one making changes anymore. The prototype got us to production. The institutional work of making it permanent and scalable is its own project entirely.
The Off-Hours Reality
I'll be direct about this: building the prototype on my own time was the right call for the outcome, but it's not a sustainable model. The only reason this particular project required off-hours work was that the organizational appetite hadn't caught up to the opportunity yet. I had to create the proof before the organization would invest in the exploration.
In an ideal state, the organization creates space for this kind of exploratory work within the normal operating rhythm — time and resources allocated for testing use cases that haven't been formally sanctioned yet. The fact that I had to do it on nights and weekends isn't a badge of honor. It's an indicator that the organization's innovation process hadn't matured enough to support the exploration within its own structure. That's changed since — partially because this project demonstrated what happens when you give someone room to build beyond the ask.
Reflection
This project taught me something I keep coming back to: the gap between what people ask for and what they actually need is where the real opportunity lives. Most people fill the order. I'd rather solve the problem — even if solving the problem means building something nobody asked for and hoping the proof speaks loudly enough to change the conversation.
It also taught me the difference between a prototype and a product. Building something that works is step one. Understanding what it takes to make it institutional — owned, governed, scalable, maintained by people other than you — is the work that most builders skip. I didn't skip it, but I'll admit it required a different set of skills than the build itself.
The Principle
Show, don't tell. When words create resistance, working prototypes create buy-in. Be brave enough to trust your own vision, confident enough to build the proof on your own time, and honest enough to acknowledge that the solo build is the beginning of the institutional work — not the end of it.
This project sits at the intersection of AI Strategy & Roadmapping, Applied AI Design, and Training & Change Management — three areas where the distance between "good idea" and "adopted capability" is almost always longer than anyone expects.