Healthcare & life sciences — dermatology field salesVoice agents & enterprise data integration

A voice-first assistant that briefs field sales reps before a pharmacy visit and writes up the visit after it

Sales reps spent the drive to each pharmacy piecing together data from three systems, and the evening typing up what happened. We built a voice assistant that does both ends of the visit, over CRM, ERP and warehouse data, with territory-based security — delivered in three weeks.

A field sales rep speaks to the assistant before a pharmacy visit (“Help me prepare for my next pharmacy”) and after it (“Just finished there — here’s what happened”). A voice agent routes each request to a pre-visit intelligence agent that pulls, aggregates and briefs, or a post-visit capture agent that structures, writes back and follows up. Every request passes a territory filter before reaching three systems via MCP: the data warehouse for sales performance, visit history and territory metrics; the CRM for customer profiles, contacts and opportunities; and the ERP for orders, billing and product purchases. A memory layer in PostgreSQL with pgvector keeps visit and conversation context across sessions, with web chat as a fallback. Results along the bottom: 50% less visit preparation, pre-visit briefings in under 5 seconds, post-visit capture in under 3 seconds, delivered in 3 weeks.
The rep asks out loud. The agents fetch from three systems, inside the rep’s territory, and answer out loud.

Project snapshot

Client
A dermatology and pharmaceutical company with a field force of 600+ sales reps across many countries
Industry
Healthcare & life sciences — dermatology
Business function
Field sales and pharmacy account management
Challenge
Before each pharmacy visit, reps assembled sales performance, visit history, customer profiles and order data by hand from a data warehouse, a CRM and an ERP — usually on the move. After the visit, notes and follow-ups had to be typed back into the CRM. Preparation ate into selling time, and every rep had to see only their own territory.
Solution
A voice-first assistant built on MCP servers over the warehouse, CRM and ERP. A voice agent routes each request to a pre-visit intelligence agent, which fetches the three sources in parallel and speaks a briefing, or a post-visit capture agent, which extracts structured data from the rep’s spoken account and writes it back. Territory-based authentication filters every read and write; PostgreSQL with pgvector keeps context across sessions; a web app covers moments when voice is not practical.
Result
50% less visit preparation time, pre-visit briefings in under five seconds, post-visit capture in under three seconds, and the whole system delivered in three weeks.

Key outcomes

50%
Less visit preparation time
< 5s
From spoken question to pre-visit briefing
< 3s
From spoken visit account to updated records
3 weeks
From kick-off to a working voice assistant

The client

A dermatology business sold one pharmacy at a time

A dermatology and pharmaceutical company with a large field sales force working across many countries. Its reps visit pharmacies to keep shelves stocked, launch campaigns and build relationships with the people behind the counter.

Each visit is short. What a rep knows walking in decides how much of it is useful.

The challenge

Three systems to check before every door, and notes to type after it

Preparing for a visit meant opening three systems on a phone. Sales performance and visit history in the data warehouse, contacts and opportunities in the CRM, order and billing history in the ERP — joined in the rep’s head, often in a car park.

The surface area

600+
field sales reps
3
systems behind every briefing

After the visit, the same rep had to type up what happened and what was promised. The preparation took selling time; the write-up took the evening, or did not happen.

Constraints

What we had to design around

  • Hands-freeReps prepare in the car, between one pharmacy and the next. Anything that needed a screen and two thumbs would not be used where it mattered. Voice had to be the main interface, with spoken answers short enough to take in while driving.
  • TerritoryA large multi-country field force, each rep assigned specific territories and customers. A rep could never hear about, or write to, an account that was not theirs — and that had to hold for every query, not just the login screen.
  • Three systemsSales performance lived in a data warehouse, customer profiles and opportunities in the CRM, orders and billing in the ERP. A useful briefing needed all three, joined on the same pharmacy.
  • Data protectionCustomer contacts and commercial data across several jurisdictions. The assistant had to stay within data protection rules from the first day, not be retrofitted later.
  • Speed to valueThe field force needed to see it working quickly. The build had to produce something a rep could talk to within weeks.

Our approach

Voice first, two agents, one territory filter

A rep’s day has two moments where information work happens: just before a visit and just after it. So we built one agent for each, rather than a general assistant that has to guess which mode it is in.

Both sit behind a voice agent, because the rep is usually driving. Both reach the three systems through MCP servers, so adding a source is a new server rather than new agent code. And the territory filter lives in that data layer, so no prompt — and no clever question — can widen what a rep sees.

The solution

Six layers, from a sentence in the car to a CRM record

  1. Voice and web interface — Speech in and speech out through ElevenLabs, with streaming responses so the answer starts before it is finished. A web app with the same login covers the moments when talking is not practical.
  2. Voice agent — Orchestrates the conversation. It works out whether the rep is preparing or reporting back, routes to the right agent, and hands the result to a response agent that turns it into something worth hearing.
  3. Pre-visit intelligence agent — Pulls sales performance, visit history, customer profile and order history in parallel, aggregates them, and produces a briefing: last visit, performance trend, key opportunity, recommended focus and who to ask for. Its tools cover data access, reasoning, data structuring and follow-up scheduling.
  4. Post-visit capture agent — Takes the rep’s spoken account, recalls the visit context, extracts structured fields and writes them back — visit record, activity log and opportunities in the CRM, performance metrics in the warehouse. It ends with next actions: the follow-up order, the next visit, the materials to send.
  5. MCP data layer — MCP servers over the warehouse (BigQuery), the CRM (Salesforce) and the ERP (SAP) give the agents one standard way to read and write, with territory filtering applied inside the servers and real-time synchronisation.
  6. Identity and memory — Territory-based authentication with role-based permissions, integrated with the existing user management. Agent memory in PostgreSQL with pgvector keeps customer preferences and conversation history across sessions.
The agent architecture. On the left, a web app panel with a voice-enabled input bubble and a voice-enabled response bubble. In the centre, a multi-agent orchestration area: a voice agent handles orchestration and passes results to a response voice agent; the voice agent connects to two specialist agents. The PreVisitIntel agent has an MCP database tool, reasoning tools, a data structure tool and a follow-up scheduling tool, plus visit memory and context memory. The PostVisit Capture agent has an MCP database tool, reasoning tools, a summary tool and a visit briefing tool, plus visit memory and context memory. On the right, external systems — SAP, BigQuery and Salesforce — feed the agents.
The two specialists in full. Each carries its own tools and two kinds of memory; the external systems on the right are reached only through MCP.
Two flows side by side. Before the visit: the rep asks to prepare for their next pharmacy; the assistant fetches in parallel from the warehouse (performance, visits, territory), the CRM (profile, contacts) and the ERP (orders, billing); aggregates and stores the context with embeddings; and speaks a briefing in under five seconds covering the last visit and what changed, the account’s performance trend, the key opportunity and recommended focus, and who to ask for. After the visit: the rep describes what happened; the assistant recalls the visit context from memory and extracts structured fields; writes back in parallel to the CRM visit record and opportunities and to warehouse metrics; and replies in under three seconds with next actions — a follow-up on the order discussed, the next visit scheduled, materials to send — with all systems updated and nothing typed. Every read and write is filtered to the rep’s own territory.
Preparation before the door opens; documentation before the next one.
3 weeksfrom kick-off to a working voice assistant — data integration first, then security, voice, memory and the web app

Responsible by design

Four rules for an assistant with access to customer data

  • Scope

    A rep sees their territory and nothing else.

    The filter sits in the data layer, not the prompt. A question about an account outside the rep’s territory returns nothing to summarise.

  • Ground

    Briefings come from the systems of record.

    Every figure in a briefing is fetched from the warehouse, CRM or ERP at the time of asking — not recalled by the model.

  • Confirm

    The rep can check before anything is written.

    Post-visit updates can be read back to the rep for confirmation before the CRM changes, so a misheard word does not become a record.

  • Comply

    Data protection from day one.

    Access controls, session management and privacy-compliant handling of customer data were part of the first build, not a later hardening pass.

The first rule shapes the rest. A voice assistant that answers anything is a data leak with a friendly tone. One that answers only inside the rep’s territory is a tool the business can hand to every rep.

Results

What changed for the field force

  • 50% less visit preparation time — the briefing that took a rep three systems and a stretch of the drive now arrives as one spoken answer.
  • Pre-visit briefings in under five seconds, with the warehouse, CRM and ERP queried in parallel and filtered to the rep’s territory.
  • Post-visit capture in under three seconds, from a spoken account to updated CRM records, warehouse metrics and a list of next actions.
  • Enterprise-grade security from day one — territory-based access, role-based permissions and data protection-compliant controls across a multi-country field force.
  • Reusable components — the MCP servers, memory and authentication now underpin further AI work across the business, not just this assistant.

Reps walk in knowing the account and walk out with the visit already logged.

Beyond the numbers

What else changes

The CRM starts to reflect what actually happens in pharmacies. When documenting a visit takes one sentence, visits get documented — and the next rep, manager or briefing works from a complete record rather than the ones someone found time to type.

And because memory carries across sessions, the assistant remembers what was promised last time. The next briefing starts there.

If your field team spends more time preparing than selling

The first question is which systems a rep opens before a visit. That is answerable from a day riding along, before anything gets built.