A WhatsApp Salesforce integration must fit the way your organisation assigns work. We start by separating enquiries that belong to an account owner from those that need a service queue, then specify the record and permissions required for each route.
We map the questions that reach the number before choosing where to route them. A request to change a proposal and a fault report may concern the same account, yet need different records and owners. The agreed map prevents the channel design from treating every message as a new lead.
For each route, we list the fields the adviser needs and the permissions available to that role. If the required information sits in a custom object, we check access and channel capabilities before promising it in the conversation view. The scope records both allowed reads and allowed changes.
A transfer needs an acceptance point: which queue or person takes responsibility and what must accompany the message. We specify how an unresolved enquiry is recognised and who checks it. The configuration is tested against those decisions with your Salesforce administrators.
In this proposed example, the customer sends a product reference and describes a fault rather than requesting a new purchase.
The planned connection relates the enquiry to the appropriate customer record and service route after checking the available channel functions.
If a replacement quote is needed, the service adviser records the request and its next owner. The sales handover is tested separately from the original support route.
We review these points before defining the scope, budget and launch.
We inventory the Salesforce products in use before selecting a route. Sales Cloud, Service Cloud and Marketing Cloud solve different parts of the process; one subscription should not be taken as evidence that the required WhatsApp channel is included. Messaging licences and add-ons are checked explicitly.
The design identifies the account, contact, lead or case involved in each sample journey. We review ambiguous matches, missing owners and restricted fields with the administrator. A successful test must show that the right employee can act without making unrelated customer information available.
We review the Meta account, current number arrangements and templates, then agree a suitable test environment. Before activation, the team needs a named person for checking incoming work and a procedure for handling enquiries if the new route fails.
We start with one workflow, validate it with your team and document how to maintain it. The scope follows your configuration.
Discuss my integrationWe review how enquiries arrive, who handles them and what information they need. Together, we choose a first use case and how to measure it.
We check licences, the number, permissions and fields. We define templates, assignment rules and how to handle failed operations.
We validate messages, records and follow-up with test cases. We refine the workflow before using it with customers.
We document the configuration and train the people responsible. We agree on support and how to review results.
We include a deliberately restricted test user in the acceptance exercise. The expected outcome is an understandable exception and a named person who can resolve it, without widening access for everyone. For example, a service adviser may need a product reference while the commercial terms remain restricted. We record that boundary and check the receiving screen, the failed operation and the next authorised step. The test evidence becomes part of the handover, so a later permissions change can be assessed against an agreed example.
We use a sample enquiry with a recognisable reference, submit the agreed journey, then repeat it after the first action has been recorded. The review checks whether another case or follow-up task appears, which record the adviser sees and whether the original owner remains visible. We also examine a delayed reply after the enquiry has been closed. Each outcome is agreed with the administrator; where the chosen route cannot distinguish a repeat reliably, the operating procedure identifies the human check needed before another action is taken.
Yes. The assessment begins with the records, permissions and assignment rules your administrators already maintain. We mark which parts can be reused and which would need a change. We do not assume a standard demonstration account represents the way your organisation works.
We write down the exact information required, the user role that needs it and whether the workflow reads or changes it. We then verify that the chosen connection supports that operation. Permission failures and missing records belong in the test plan, alongside the successful example.
Your administrators and the receiving teams review a set of agreed journeys. For each, we check the destination record, the person responsible and the result of the reply or transfer. Any manual exception is documented before the team signs off the configuration.
A service conversation does not define the requirements of a campaign. If marketing messages are in scope, we assess the relevant Salesforce product, permissions and WhatsApp sending conditions separately. The proposal distinguishes that work from the support and sales journeys already agreed.
Tell us your CRM or ERP, its plan or version and the process you want to connect with WhatsApp. We will review your setup and the next steps.