# How to choose the right Salesforce consulting partner for enterprise rollouts Ask who the architect is after the sale, for a reference in the cloud you are buying, and for a project they told a client not to do. **Published:** 2025-12-18 **Canonical:** https://synconai.com/choose-salesforce-consulting-partner **Author:** SynconAI Architecture Team ## In short Choose a partner by three questions. Who is the architect after the sale, not only during it. Can they give you a reference in the cloud you are buying, such as Agentforce or Field Service. Will they name a recent project they told a client not to do. A team that has not delivered that cloud is the usual failure. ## Sources - **Agentforce: The AI Agent Platform** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > Agentforce is the AI agent platform that delivers 24/7 autonomous support at enterprise scale. - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce. ## What to take away - Name the architect who stays after signature. "To be confirmed" is a vacancy. - Ask for a reference in the cloud you are buying. An Agentforce reference does not cover Field Service, or the reverse. - Ask for a recent project they advised against. A firm that has never refused work will not refuse yours. - The consultancy linked from this page is one firm. Run the same three questions everywhere. ## The guide Choose a Salesforce partner for an enterprise rollout by three questions, asked without a slide in the room. Who is the architect after the sale. Can they introduce a reference in the cloud you are buying. Will they name a recent project they told a client not to do. A firm that cannot answer is selling staff, not a result. The failure arrives a month after signature. The proposal named a senior architect. That person is now "supporting from the background", which means they are on a different account. The people configuring the org have delivered Sales Cloud. The work you bought is Agentforce. They discover grounding and permissions in production, because the pilot only passed on an administrator login, and nobody in the room had stopped a design for that reason before. A Field Service rollout staffed the same way discovers territories, skills, and travel in the first week technicians are live. The discovery is the failure. It is expensive because the customer is already in it. The questions below are how you see it while the proposal is still a proposal. The product split is why the questions have to be specific. Salesforce describes Agentforce as the agent platform for autonomous support at enterprise scale. Agentforce Field Service and Operations, formerly Field Service, is a different product: a field service hub. A reference for one says nothing useful about the other. A logo wall is not a reference. ## The architect after the sale Ask for the person who will still be on the account when the workshops are over. You want a name, and you want that person in the meeting. Their job is to reject a design that will not survive contact with your org, not to repeat the proposal. Ask them, in the room, what they would refuse on this rollout. A person who cannot name a refusal is reading the slide. A person who names one, and says what they would do instead, is the architect. Ask what that person has shipped in the cloud you are buying, in the last two years. An Agentforce pilot staffed by people who have only configured Sales Cloud objects will discover grounding and permissions in production. A Field Service rollout staffed by people who have never scheduled a territory will discover the gap in production. That discovery is the failure mode. Staff the cloud with people who have done it, or do not start. "We have a Salesforce practice" is true of a great many firms, and it does not answer the question. The practice is not the cloud. Ask how many of the proposed team have delivered that cloud, and whether they are employees you can meet. A proposal that names seniors in the pitch and staffs the build from a different product is the same failure, a month later. If the architect is "to be confirmed" after signature, you are buying a vacancy. Write the name into the agreement as the person who stays, and write what happens if they leave: a replacement you have met, with the same cloud on their record, before the build continues. A substitution clause that says "or a resource of equivalent experience" is how the Sales Cloud team arrives. Equivalent to what, in which cloud, decided by whom. If the clause cannot answer that, it is not a clause. It is a gap. For an agent rollout, ask the architect to walk two use cases, a data owner, a permission review, and a kill criterion, against your org rather than against a sample. That is the shape of a strategy that can be stopped, set out in [an enterprise AI strategy on Salesforce](/enterprise-ai-strategy-salesforce). A firm that answers with a catalogue of agents has not done the work. For a field rollout, ask them to name who owns the work order, what a territory means in your operation, and which design they would refuse because the data is not ready. The cloud changes. The test does not. You are listening for a refusal that is specific to the thing you are about to buy. ## A reference in that cloud Ask for a customer you can call who bought the same cloud, at a similar scale. Agentforce if that is the work. Field Service if that is the work. A contented Sales Cloud reference does not speak for either, however large the programme was. Scale without the cloud is a story about a different project. Take the call without the partner on the line. On the call, ask what the partner refused, what went wrong, and who from the partner was still there in month four. You are listening for a specific system, a specific argument, and a specific person. General praise is easy to give and useless to you. If the reference cannot remember the architect's name, you have learned something. The architect in the proposal and the architect on the account were not the same fact. Ask what the reference would do differently, and whether they would hire the firm again for a second cloud. A yes on the second cloud, with no example, is cheer. A yes that names a different team, or a no that names the gap, is information. Write down the name they give you and compare it with the name in your proposal. If they differ, ask why before you sign, not in month four when the answer is a roster change you have already paid for. A reference who describes a smooth path and cannot remember a disagreement has either had a very small project or has been asked to be polite. Polite is not a defect in them. It is a reason to ask a sharper question. What did you almost buy, that this firm told you to leave. If the answer is still empty, thank them and treat the reference as weak. Weak does not mean the firm is bad. It means this call did not show you the cloud. ## A project they advised against Ask for a recent project they told a client not to do. A real answer names the cloud, the reason, and what happened instead. The data was not ready. The cloud was the wrong product. The timeline could not hold the integration. "We always find a way" is a sales sentence. A partner who has never advised against a project will not advise against yours, including when you are about to buy the wrong thing. Listen for the integration version of that refusal. A firm that has never told a client to stop because nobody owned the field will not stop you either. Who owns each attribute, who funds the pipe after the project, and who is called when it fails are the programme decisions in [integration at programme level](/insights/enterprise-salesforce-integration-best-practices). You do not need the firm to recite a method. You need them to have refused a design in which two systems both wrote the same fact. If every story ends with a connector, they have not yet met the part that makes rollouts fail. A useful answer is boring and specific. "They wanted Agentforce on service before the case fields were fit to quote. We told them to fix the source list first. They did the source list with their own admin, and we came back for the pilot." Or, "They wanted Field Service to schedule work the warehouse system already owned. We told them to leave the appointment where it was and put a status on the case. They hired someone else to build the second scheduler." Both answers tell you the firm can walk away from revenue. A firm that cannot tell you a story like that, with a cloud and an outcome, is telling you that your project will not be the first time they decline. It will not be declined. ::: note Ask the three questions of every firm on the list, including the one linked from this page. A firm that answers them is worth a second meeting. A firm that answers with a logo is not. The link is not a prize, and it is not a ranking. ::: ## What you are not buying You are not buying a headcount, a certification wall, or a promise that the tool is the strategy. Certifications show that someone sat an exam. They do not show that this architect stayed after signature on this cloud. A case study without a person you can call is an advertisement. Treat it as one. The call is the reference. The PDF is not. You are also not buying a single firm for every cloud in the estate. A firm that can answer the three questions for Agentforce may be the wrong firm for Field Service, and the reverse. Split the work if the answers split. A partner who insists the same team covers both, and cannot produce a reference for one of them, is asking you to fund their learning. You can choose to do that, with your eyes open, on a small pilot, with the architect named. You should not choose it by accident inside an enterprise rollout. The consultancy linked from this page is one firm that does this work. It is not the only one, and this page is not a prize. Run the three questions there and on every other firm on the list. Hire the one that can answer them for the cloud you are buying. If none of them can, do not start. A vacancy with a logo on it is still a vacancy. ## How to run the conversation Put the three questions in the invitation, so a firm that needs a week to find a reference can say so, and a firm that intends to improvise cannot. One hour. The architect in the room. No slide deck until the questions have been answered. If the deck comes out first, ask them to close it. You are not being rude. You are buying a result, and the deck is how a vacancy hides. Take notes in their words. The name. The cloud they say they shipped. The reference's cloud, which you will check. The project they refused, including what the client did instead. Compare the notes with the proposal the next day, not in the room. Differences are the finding. A proposal that lists six clouds and a conversation that can support one is a proposal for one cloud. Buy that, or buy nothing. Do not buy the six because the cover said enterprise. Score nothing. A matrix of logos against "strategy", "delivery", and "culture" will crown the best talker. The three questions are yes or no in practice: you met the architect, you can call the reference, you heard a refusal with an outcome. A firm that is yes on all three goes to a second meeting, on your org, with the same person. A firm that is no on one does not get a workshop to recover. Workshops are where the wrong team becomes familiar, and familiar gets signed. ## Questions ### How do we choose a Salesforce consulting partner for an enterprise rollout? Ask three things, without a slide in the room: who is the architect after the sale, whether they can give a reference in the cloud you are buying, and whether they will name a recent project they told a client not to do. A team that has not delivered that cloud is the usual way these projects fail. The failure shows up in production, as grounding, permissions, or scheduling discovered by people who have not done that cloud. Ask every firm on the list the same three questions. ### Why does the cloud on the reference matter? Agentforce and Field Service are different products. Salesforce describes Agentforce as the agent platform, and Field Service, now Agentforce Field Service and Operations, as the field service hub. A reference for one does not cover the other. A contented Sales Cloud reference, however large, is a story about a different project. On the call, ask what the firm refused, what went wrong, and who was still there in month four. ### What if the architect is named only in the proposal? Ask whether that person stays after signature, and whether you can meet the people who will configure the org. To be confirmed is a vacancy. Seniors in the pitch and a different cloud on the build is the failure mode. Write the name into the agreement, and write what a replacement must have shipped. A clause that says equivalent experience, with no cloud and no judge, is how the wrong team arrives. ### What does a useful "we advised against it" answer sound like? It names the cloud, the reason, and what the client did instead. Data not ready, wrong product, or an integration the timeline could not hold. We always find a way is not that answer. A useful story includes an outcome: the client fixed the data and came back, or the client hired someone else to build the thing the firm refused. A firm that has never walked away from revenue will not walk away from yours. ### Is one consultancy the right partner for every cloud? No. The firm linked from this page is one option, and the same three questions apply to every firm. Hire the one that can answer them for the cloud you are buying. A firm that can answer for Agentforce may be the wrong firm for Field Service, so split the work if the answers split. If none of them can answer, do not start. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).