Four AI ideas are usually four different systems
A financial-advisory workflow shows why a call summary, a coaching scorecard, an internal chatbot, and a compliance checker should not be treated as one AI project.
“We want AI for the team” sounds like one project. It almost never is.
In a recent solution-design engagement with a financial-advisory business, a leadership team had a sensible wish-list: turn advisor-client calls into useful notes, coach advisors from their sales conversations, answer internal questions quickly, and catch problems before a case was submitted.
All good ideas. All useful. But they were not four screens in one app. They were four different systems with different inputs, different definitions of “right,” and different risks when they get something wrong.
Treating them as one big “AI platform” would have made the first version slower, more expensive, and harder to trust. The useful work was separating them before choosing a model or drawing a dashboard.
The same meeting can create four very different AI jobs
Here is how I separated the work.
1. Capture: turn a conversation into usable information
A meeting-recording system has to hear names, numbers, products, next steps, and personal goals correctly—often across accents and languages. Its job is extraction. The output should be structured notes or fields that a human can check, not a confident-sounding summary alone.
2. Coach: judge a conversation against an agreed rubric
A coaching system needs a different input: a definition of a good first appointment, fact-find, or referral conversation. It cannot invent that definition. Someone experienced has to provide and refine the rubric, and supervisors need a way to override a bad score.
3. Answer: find the right internal knowledge
An internal Q&A assistant is mostly a retrieval problem. It needs approved source material, a clear owner who updates it, and a way to show the source behind an answer. Old chat histories can help reveal common questions, but they are not automatically a reliable knowledge base.
4. Validate: flag a risky or incomplete submission
A submission checker should be the most conservative of the four. Its job is not to approve a case. It is to spot missing fields, inconsistent details, or items that need human review before the case moves on.
They may all use language models. That does not make them the same product.
The mistake: buying the dashboard before defining “correct”
The tempting plan is to start with a shared login, a large dashboard, and every feature behind a menu. That feels strategic. It is usually the opposite.
For each workflow, there is one question that has to be answered first:
| Workflow | The question that matters before building |
|---|---|
| Call capture | Which fields must be accurate enough to rely on? |
| Coaching | Who decides what good looks like, and can they change it? |
| Internal Q&A | Which documents are approved sources, and who maintains them? |
| Submission checks | What should be flagged, and who has the authority to clear it? |
If the team cannot answer that question, an AI system will make the ambiguity look polished. It will not remove it.
This is why I prefer a narrow first build. For the advisory workflow, the natural first step was not “an AI sales platform.” It was one bounded workflow with clear source material and a human checker—for example, extracting agreed fields and next actions from recorded conversations, or flagging obvious gaps in a submission.
That first version creates the things the larger plan needs: real samples, an agreed definition of quality, a place for exceptions, and a team that knows what they would actually use.
Share the plumbing later, not the problem too early
There are components worth sharing across AI workflows: sign-in, permissions, audit logs, data storage, monitoring, and perhaps a common transcript store.
But shared infrastructure is not a reason to force workflows together on day one. A transcription system cares about accuracy and language handling. A coaching system cares about rubric consistency. A chatbot cares about source freshness, and about checking its answers before a customer sees them. A compliance checker cares about false negatives.
Those are different failure modes. They deserve separate success measures.
The right sequence is usually:
- Pick the workflow with the clearest repeated pain.
- Define what a correct result looks like, with examples.
- Build the smallest version with a human override.
- Measure errors, usage, and time saved.
- Reuse the parts that earned the right to become shared infrastructure.
That is slower than promising a full “AI transformation” in the first meeting. It is much faster than rebuilding a large platform after nobody uses it.
Solution design is deciding what not to build yet
The most valuable output from an early AI conversation is often not code. It is a better order of operations.
In this case, the final roadmap had multiple systems and a sensible shared foundation. But the important decision was to make the boundaries visible: extraction is not coaching; coaching is not knowledge search; knowledge search is not compliance review.
Once a team sees those boundaries, it can choose a first workflow based on risk, value, and readiness—not on whichever AI demo looks most impressive.