Key account managers in pharma work across a sprawl of accounts, each with its own hierarchy, performance picture, payer mix, and competitive context. The tools built for them mirror that sprawl: dashboards per account, per metric, per system — with the KAM doing the integration manually, one account switch at a time.
In the field, that model breaks down completely. A KAM preparing for a meeting doesn’t want to navigate; they want to ask.
Mention an account in a question, and the context follows you — navigation becomes a side effect of asking.
The Approach
I designed a conversational platform where structured data and dialogue work together rather than compete. The conversation is the spine; 12 structured data modules — account hierarchy, performance KPIs, payer mix, peer benchmarks, and more — are the evidence it draws on and renders in place.
The defining move was the navigation model. Traditional account tools make you select an account, then explore it. Here, the query drives everything.
On evidence: my proxy users were Trinity’s own commercial consultants — domain experts who advise pharma on account strategy — not key account managers at client companies. That distinction matters more on this project than on anything else I’ve shipped. An SME at a desk will happily type a question. Whether a KAM will do the same at 7am in a parking lot, ninety seconds before a meeting, is the exact assumption the whole navigation model rests on. The closing section is honest about that.
Evidence base — internal SME review · domain-expert working sessions · stakeholder walkthroughs. No direct end-user testing.
1 / 5One conversation, twelve structured modules
Key Decisions
Query-driven navigation
Mentioning an account in a question routes the context automatically — eliminating manual account switching and letting a KAM move across their whole book of business in one conversation.
Structured modules inside the conversation
12 data modules give AI answers a consistent, scannable shape — hierarchy, KPIs, payer mix, and benchmarks render as structured surfaces, not paragraphs of generated text.
Built on the Trinity AI pattern language
Chat threading and structured-response patterns from the design system’s AI module keep the copilot consistent with the rest of the portfolio — and trustworthy by default.
Outcome
×12structured data modules unified in one conversational surface
0manual account switches — context routes from the question itself
KAM Field Advisor is what enterprise AI looks like when conversation and structure are designed as one system — an assistant that answers like a colleague and presents like an analyst.
What I’d Validate Next
Designing against internal experts got the model right in principle. These are the three things I’d put in front of real KAMs before claiming it’s right in practice.
Will a KAM think to type an account name?
Query-driven navigation is invisible until someone uses it. I’d run an unguided first-run test and count how many KAMs mention an account unprompted versus hunt for a picker. A low number wouldn’t make the model wrong — it would mean it needs a first-run affordance I didn’t design.
How many of the twelve modules earn their place?
Twelve structured modules is a claim about coverage, not about use. I’d instrument which ones actually get returned and read. If it’s consistently three, that isn’t a failure — it’s a prioritisation I should have made at design time and can still make now.
Does it survive the field?
Every screen here was designed and reviewed at a desk on a large monitor. The real context is a phone, poor signal, and the ninety seconds before a meeting. I’d do ride-alongs before trusting a single interaction target in this design.
