How a salesforce-native saas replaced manual crm navigation with conversational agents

Wippy

Runtime

Salesforce

agent orchestration

Multi-tenant

architecture

Solutions

AI Agent Automation, AI Strategy & Implementation

Industries

Artificial Intelligence, Business Automation, Technology

Technologies

AWS, Claude (Anthropic), React, Temporal, Websockets, Wippy AI

About THE Project

The client builds a custom CRM product on top of Salesforce for distribution and manufacturing companies. Their product isn’t a Salesforce extension but it’s a vertical CRM where the entire sales process lives like territories, quotes, invoices, account history, and sales playbooks all baked into their own Salesforce org structure.

The problem was that sales reps weren’t using it. Not because the product was useful, but because the interface required too much cognitive overhead. Reps had to know which custom objects to navigate, which fields were meaningful, and how to manually piece together account context across five different screens before they could take any productive action. Adoption was stalling. The CRM was full of data that no one was actually using.

The obvious answer was a natural-language interface. But when they tested off-the-shelf AI chatbots, every one of them broke on contact with their actual Salesforce environment. Standard LLM wrappers don’t know how to navigate territory-based access rules, query across multi-object relationships (opportunities linked to quotes linked to invoices), or factor in proprietary sales playbook logic that lives outside the CRM entirely. The client needed something architected for their actual system, not a generic demo built on clean test data.

We architected a multi-agent orchestration system built on the Wippy platform. We shipped a production-ready conversational CRM agent that securely connects account-level Salesforce data with the client’s internal sales logic. Now, instead of clicking through endless UI screens, sales reps can use natural language to instantly query accounts, log activities, and receive playbook-driven strategic recommendations. We turned a static database into an active, automated workflow engine.

CORE OBJECTIVES

Replace UI navigation: Shift from traditional Salesforce screens to a natural-language conversational interface.
Connect account-level data: Enable AI agents to query and summarize opportunities, contacts, quotes, and invoices in real time.
Integrate proprietary logic: Feed client sales playbooks into agent responses for context-aware recommendations.
Validate multi-tenant scale: Prove the multi-agent architecture can scale across 30+ isolated customer Salesforce orgs without manual tool replication.
Transfer engineering knowledge: Ensure the client’s team can stand up and orchestrate additional agents independently.
Assumption: Reduce manual CRM update time by 50% and achieve 70%+ end-user adoption within the first 90 days of deployment.

Challenges

Solutions

Challenges

Integrating via API-Only Access

The client’s architecture relies on org-level authentication, not per-user logins. Their custom Salesforce security layer dictated that every interaction with the AI agents had to execute via API rather than a native UI. We needed to ensure agents and tools could be consumed programmatically without compromising their strict access controls.

Solutions

WebSocket and REST API Endpoints

We provided the underlying WebSocket protocol and architected the system so the client’s React front-end calls the Wippy agents strictly through the API. This kept the authentication layer entirely on the client’s side, preserving their security model while exposing full agent capabilities.

Challenges

Agent and Workflow Creation Usability

The client’s engineering team could build individual tools, but composing those isolated tools into multi-agent workflows created a steep learning curve. Workflow orchestration was the primary value driver, but the path to building it wasn’t intuitive enough for immediate self-service.

Solutions

Guided Co-Building and Knowledge Transfer

Instead of handing off static documentation, we ran guided working sessions to co-build the agents. We structured multi-step workflows and established starter templates together, ensuring the client acquired the practical exposure needed to build independently.

Challenges

Multi-Tenant Deployment Constraints

The client serves 30+ customers, each with an isolated Salesforce org. Replicating Wippy orgs, tools, and agents for every single customer would create a massive, unscalable maintenance burden whenever models or workflows required updates.

Solutions

Centralized Registry Architecture

We designed a multi-tenant deployment model where agents and workflows live in a central registry. Using feature toggles and Git-based version control, the system selectively deploys customer-specific experiences without hard duplication, establishing a path for automated provisioning.

Challenges

Knowledge Base Integration and Testing

The client needed to pair structured Salesforce data with unstructured sales playbooks, but lacked a reliable way to verify if agents were successfully ingesting the documents and factoring them into their reasoning.

Solutions

RAG-Backed Knowledge Strategy

For the initial phase, we embedded playbook content directly within model instructions to validate the output accuracy. We then defined the architecture for a full RAG-backed knowledge base with search capabilities to support scalable document ingestion in Gen 2.

project Strategy

Our architectural approach was dictated by production constraints, not feature lists. Instead of chasing maximum AI capability on day one, we prioritized early validation, system survivability, and client independence over building a black box.

Prove the Hard Stuff First

Before writing a single line of application code, we ran a focused sandbox pilot with one goal: prove that a WebSocket and API-only approach could navigate the client’s Salesforce org-level security without special permissions or hacks. Salesforce’s enterprise permission model has broken a lot of AI integrations at exactly this step. We needed to know whether it would break ours before we committed to the full build. It didn’t. Once we had that validated, we moved forward with confidence on the MVP.

Build It Together, Not For Them

The client needed to merge two very different types of knowledge. First was structured CRM data from Salesforce and second was unstructured sales playbook content that existed in documents and internal guides. Instead of immediately engineering a full RAG pipeline, which would have taken longer and added failure points we injected the playbook logic directly into model instructions to validate accuracy first. At the same time, we ran co-build sessions where the client’s engineers worked alongside ours, building Temporal workflows in real time. By the end of the engagement, their team wasn’t waiting for instructions. They were independently structuring their own sub-agent workflows. That was a design goal, not a side effect.

Multi-Tenant From Day One

A conversational interface that only works for a single customer org is a proof of concept, not a product. The client had 30+ isolated Salesforce orgs to support. We designed a centralized agent registry managed through Git-based version control so that adding a new customer org didn’t mean rebuilding the agent from scratch. We made a deliberate short-term tradeoff: some manual provisioning in the initial release in exchange for shipping the core product faster. The architecture for fully automated org deployment is already defined and it’s the next phase of their roadmap, not a future design problem.

Project results

The engagement closed with a deployed, production-ready system and a client team that can extend it themselves. Here’s what shipped.

Tangible outputs shipped during the engagement:

– Conversational CRM Agent: Handles natural-language queries against real Salesforce account data, returning accurate results across opportunities, contacts, quotes, and invoices. Not summarized mock data. Actual live org data, queried securely via API.

– Salesforce Object Summaries: Automatically surfaces everything linked to a given account in a single response, eliminating the multi-screen navigation that was killing adoption.

– Knowledge Base Integration: Sales playbook content is queryable by the agent, so recommendations aren’t just data lookups — they’re informed by the client’s actual sales methodology.

– Embedded Protocol: Delivered the protocol spec and implementation reference for the client to embed the conversational layer directly in their existing React front-end.

– Modular Architecture: Every component is designed so the client can add new sub-agents, expand tool coverage, and onboard new customer orgs without starting over.

Key Takeaways

This project validated the architectural pattern the client’s entire product roadmap now sits on. Multi-agent orchestration, multi-tenant Salesforce integration, and playbook-aware AI responses all in a production system, not a demo environment. The client’s engineers can extend it. The client’s customers can use it. And the system runs on their infrastructure, with their LLM costs, without a dependency on us to keep it working.

Worth thinking about if you’re building a conversational layer on top of Salesforce for a multi-tenant SaaS product.