What Should You Ask a Salesforce Consultant Before You Hire One?

TL;DR

• The questions you ask before hiring a Salesforce consultant decide most of what happens after. Ask them in writing and compare the answers side by side.
• Cover six areas: understanding of your problem, data, how they build, testing and governance, handoff, and how the commercial terms work.
• Strong answers are specific and sometimes say “no”. Vague answers, guaranteed dates and claims you cannot check are the warning signs.

Most hiring conversations with consultants are really sales conversations. That is normal, but it means the important details (who builds, how things get tested, what you own at the end) often come out after the contract is signed. A short, written set of questions fixes that. It also makes it easy to compare candidates fairly.

Here is a vendor-neutral list you can copy. It works for classic Salesforce projects and for Agentforce work, where the consultant is helping you put digital workers into production rather than just configuring screens.

1. Questions About Your Problem

These tell you whether the consultant listened.

• In your own words, what problem are we trying to solve, and how will we know it is solved?
• What would you build first, and what would you leave for later?
• Is there anything in our request you think we should not do?
• Which parts of this could standard Salesforce features handle without custom work?

A good consultant will push back on something. If every idea you bring is “great”, you are hearing a pitch, not advice.

2. Questions About Your Data

Data problems sink more projects than code does, and agents make this worse because they act on whatever they find.

• What do you need to see in our org before you can estimate the work?
• How will you check duplicates, missing fields and sharing rules on the objects involved?
• If an agent needs knowledge articles or Data Cloud data, how will you decide what it is allowed to retrieve?
• What happens to the plan if the data turns out to be worse than expected?

3. Questions About How They Build

• Who exactly will configure, code and test our work? Can we meet them before we sign?
• How do you work across sandboxes and production, and what does a release look like?
• For an agent: how do you define its topics, actions and human-in-the-loop handoff points?
• Where would you use Flow, where Apex, and where an external integration such as MCP?
• How do you document what you build so our admins can follow it?

You are looking for named people, a repeatable process and clear reasons behind technical choices.

4. Questions About Testing and Governance

• How do you test normal cases, edge cases and attempts to misuse the agent?
• Which guardrails do you configure, and which do you recommend we own?
• How are permissions set for the agent and its integration user?
• What gets logged, who reviews transcripts and how often?
• How do you handle prompt injection and actions that reach outside Salesforce?

If testing is described as “user acceptance at the end”, ask again. For agents, testing is part of design.

5. Questions About Handoff and Ownership

• What will our team own and be able to change on its own after go-live?
• What training, documentation and runbooks are included?
• Who owns the code, configuration and any reusable components you build?
• If we part ways, what would a clean exit look like?

A consultant who is comfortable answering these is planning for your independence, not your dependence.

6. Questions About Commercial Terms

You do not need final numbers in the first call, but you do need to understand how the engagement is structured.

• Is the work fixed scope, time-based or phased? What triggers a change request?
• What do you need from our team each week, and from whom?
• How do you report progress, and what happens if a milestone slips?
• Which Salesforce licenses or add-ons will we need, and who confirms that with Salesforce?

How to Read the Answers

Put the answers side by side and look for three things:

1. Specifics. Named people, named steps, named Salesforce features. Generic language is a sign the work has not been thought through.
2. Honest limits. A good consultant tells you what they would not do and when an agent is the wrong tool.
3. Checkable proof. A walkthrough of past work or a working agent, sample documents, or a reference you can call. Ask whether each example came from a client project or an internal build. Claims without proof do not count.

Warning Signs

• A go-live date before anyone has looked at your org.
• Answers that change depending on who on their side is in the room.
• “We do everything” with no examples of what they have actually built.
• Reluctance to put the builders on the call.
• Results figures with no project behind them.

Use It in Your Process

Send the list before the first call, ask for written answers and keep a short scorecard.

Where Funnelists Fits

Funnelists builds custom AI apps and portal templates on Salesforce, from the Miami / Fort Lauderdale area, serving clients across the US. We have built Agentforce into our SF Support Portal Template and SF Custom Portal Template, along with example agents. Send us these questions too. We would rather earn the work with specific answers.

If you are getting ready to hire for a Salesforce or Agentforce project, book an intro call and bring this list.