The best questions do not corner the vendor. They make scope, accountability, architecture, cost and outcome verifiable.
Ask for the answers in writing. Some have to go into the contract or the Statement of Work; others become technical annexes, the project plan, a RACI matrix, a test plan or a transition plan. The objective is not to make the relationship with the partner rigid: it is to remove ambiguity before it turns into cost, delay or mismatched expectations.
How to use this guide
You do not need to ask everything on the first call. If you are still comparing partners, send them with the request for proposal. If you already have a proposal on the table, use them in the clarification phase before signing.
In every answer, look for five things:
- a clear scope;
- a named owner;
- an expected output or decision;
- an explicit assumption;
- a point at which the answer will be verified.
"We will define that during analysis" can be a legitimate answer. But it has to make clear who will define it, through what activity, by when and with what effect on time and cost.
Strategy and scope
1. Which business problem does this proposal solve?
Ask them to describe the problem without naming the technology first. A solid answer identifies the process involved, the users affected, the current operational problem, the expected result and why Salesforce or Agentforce is the right fit.
Why it matters: if the partner starts from products rather than from the problem, you risk buying a solution before the use case has been defined.
2. What is included and what is explicitly excluded?
Do not ask "is everything covered?". Ask for a written list of features included and excluded, systems involved in integrations, data migrations in and out of scope, environments, training, support and hypercare, work that falls to you, and work handled by third parties.
Why it matters: change requests rarely come from new requirements. They come from work each side assumed was included.
3. Which assumptions could change the estimate, timeline or scope?
Ask them to state every assumption underlying the offer: data availability and quality, existence of the necessary APIs, user availability for workshops and testing, number of processes or business units involved, security and legal approval timelines, environment access, availability of internal decision-makers.
Why it matters: no quote exists without assumptions. The risk is not that they exist, it is discovering them after kickoff.
4. Which alternatives did you consider, and why are you not proposing them?
Ask what simpler solution they weighed, what would be possible without Data 360 or Agentforce, which use cases they would suggest deferring, and which part of the scope they would tackle in a second phase.
Why it matters: a capable partner does not always propose the widest scope. They can tell what is needed now from what can be validated or deferred.
Architecture and integrations
5. What is the proposed architecture and what are its dependencies?
Ask for an architecture diagram, not a sales slide. It should show source and target systems, data flows, integrations and middleware, where the data lives, which system is the system of record, Salesforce and external components, the development, test and production environments, and dependencies on third-party licences or teams.
Why it matters: architecture makes visible the dependencies a feature list hides.
6. Why this architecture and not a simpler or headless one?
Ask why a Salesforce-native agent is needed rather than using Salesforce as the system of record and making data and actions available in ChatGPT, Claude, Slack or Teams; what concrete advantages the proposal offers on adoption, security, governance and maintenance; and what costs and limits it introduces relative to the alternatives.
Why it matters: the starting point for the decision is not the platform. It is where users work, which actions they have to take and which system has to govern data and permissions. The comparison between the two roads is in What Agentforce really costs.
7. Which integrations are needed and who is accountable for them?
For each: which system supplies or receives data, which data is read or written, whether documented APIs already exist, who develops and who maintains, who owns the external system, what volumes and limits are expected, which activities depend on other vendors.
Why it matters: an integration is not "connecting two systems". It is a set of responsibilities, security, error handling and maintenance, and it has to be assigned explicitly.
Data, security and AI
8. Which data will the solution use, and what is the correct source for each?
Ask for a map of the data critical to the use case: what is needed, where it comes from, who is accountable for it, how often it is refreshed, whether duplicates or conflicting sources exist, and which quality checks will run before release.
Why it matters: data quality and governance are necessary conditions for reliable results, all the more so when an agent has to read that information and act on it. It is the subject of Salesforce's material on security and governance for agentic solutions and on data strategy.
9. What permissions will each user have, and what can the agent read or change?
Ask for an access matrix by role and use case: who sees which type of data, who can trigger actions, which actions the agent performs autonomously, which require human approval, how personal or regulated data is handled, and which logs and audit trails will be available.
Why it matters: an agent introduces an additional layer of access and automation. The solution has to respect least privilege, access control, traceability and data protection.
10. How will you test the agent's accuracy, security and behaviour before go-live?
This question should produce a test plan: which real scenarios will be exercised, which users will take part, how wrong answers are handled, how prompt injection, unauthorised access and edge cases are tested, which minimum thresholds are required to go to production, and who signs off the release.
Why it matters: testing an agent does not only check whether it answers, but whether it protects the data, respects permissions, acts correctly and stays observable after release. Salesforce itself ties agent adoption to trust and how well people have been prepared.
11. What happens when the solution gets it wrong or cannot complete an action?
Ask for the exception-handling process: how the error is detected, whether the user can correct it or ask for help, when escalation to a person is triggered, who analyses recurring errors, how prompts, data and instructions get corrected, and how quickly significant incidents are handled.
Why it matters: a good project does not assume the agent is always right. It designs how the organisation detects and reduces errors over time.
Cost and commercial terms
12. What is the full cost over 24 months?
Ask for a separate estimate for licences and renewals, implementation, integrations, data migration and remediation, variable consumption, support and maintenance, training, third-party products and the work required from your own teams.
Why it matters: year one can contain discounts and one-off activities. Over 24 months the recurring costs become visible.
13. Which costs depend on volume, usage or conditions not yet certain?
Which volume was assumed, which consumption unit applies, what margin of error was allowed, which costs appear if volume grows by 25%, 50% or 100%, whether alert thresholds or spending caps exist, and which part of the cost stays with the partner and which with you.
Why it matters: a consumption forecast is a hypothesis. It has to be documented, monitored and revised after the pilot.
14. Which components shown in the demo require additional licences or products?
Ask for a simple matrix, one row per capability you saw:
| Capability shown | Product or edition required | Included in the proposal? | Additional cost |
|---|---|---|---|
| Agent over internal knowledge | Agentforce + data source | yes / no | to be stated |
| Real-time external data | Data 360 + integration | yes / no | to be stated |
Why it matters: a demo shows what is possible. The contract has to make clear which of those possibilities you are actually buying.
Team, governance and continuity
15. Who will work on the project, and at what availability?
Ask for the name, role, seniority and allocation percentage of the sponsor, solution architect, project manager, technical lead, data, integration and security specialists, AI roles and post-release support team. Ask too whether the people involved in presales will follow the start of the project and the architecture.
Why it matters: the sales team does not need to become the delivery team. What you need is continuity between what was promised, the architecture defined and the people who will execute.
16. Which responsibilities stay with us?
Ask for a RACI matrix covering functional decisions, data availability and quality, security and compliance, environment access, backlog priorities, user acceptance testing, training and adoption, and operational management after go-live.
Why it matters: a partner can build a solution, but cannot replace the process owner, the data owner or whoever holds the internal decision.
17. What will our team need to be able to do when the project ends?
Ask for a transition plan: documentation handed over, training provided, operating procedures, user and permission management, integration management, the process for future changes, ownership of code and configuration, and support after go-live.
Why it matters: the outcome is not a solution released. It is an organisation able to govern it and evolve it.
Outcome and project control
18. How do we define success before we start?
Every use case should have an initial baseline, an outcome metric, a measurement date, a data source to calculate it from, an owner for the verification and a criterion for extending, correcting or stopping.
Why it matters: a solution can be technically correct and create no value. The metric is what separates the two.
19. What are the main risks, and how will you manage them?
Ask for an initial risk register with the risk, probability, impact, owner, mitigation and the condition that triggers escalation.
Why it matters: a reliable partner does not promise there are no risks. They make them explicit and propose how to handle them.
20. What do you suggest deferring, simplifying or not doing?
A useful answer sounds like this: let us start from one process rather than five, let us not connect every system at once, let us use the data already available first, let us defer automating the riskiest actions, let us validate adoption before extending.
Why it matters: being able to reduce the initial scope is a sign of maturity. A project can be ambitious without trying to solve everything in the first release.
The six questions I ask
Anyone who has run a significant purchase asks the previous twenty in some form. These six are asked by people who own the platform and keep it after the project has ended and the partner has gone. They are the ones that cost the most when nobody asked them.
21. What do you leave inside our org?
Ask for the exact count of custom objects, fields, flows, classes, permission sets and managed packages the project introduces, and their impact on the platform's limits.
Why it matters: the project ends, the org stays. Every object added is maintenance inherited by whoever owns the platform, and it appears in no quote. On an org with ten years of accumulated layers, it is the line that decides what the next project will cost.
22. How do you fit into our release cycle?
Sandboxes and how they are refreshed, branching strategy, deployment windows, conflicts with releases already planned, and who resolves a merge that touches the same flow.
Why it matters: a live platform already has a release train. A project that assumes it can deploy whenever it likes produces a delay that is not in its plan: it is in yours.
23. What breaks that works today?
Ask for a regression test plan covering the existing processes, not just tests on the new work. And ask who runs it.
Why it matters: the most expensive damage is not the new project failing. It is the process that worked and stops, because that one already has users, volumes and expectations.
24. Which of what we build will become standard product?
Salesforce ships three times a year. Ask which parts of the scope are already announced as native features, and when.
Why it matters: hand-building something that arrives natively two releases later is money wasted plus the maintenance of a duplicate. A partner who follows the roadmap can answer; if they cannot answer, you have learned something anyway.
25. If we stop after the pilot, what is left to dismantle?
Ask for the cost and procedure of rollback: what has to be uninstalled, which data remains and in what format, which processes go back to manual, and how long it takes.
Why it matters: if stopping costs more than continuing, the stop criterion you wrote at the start of the project cannot be exercised. And a criterion you cannot exercise is not a criterion: it is a sentence in a plan.
26. Whose name is on the licences?
Direct purchase from Salesforce or resale through the partner, and what happens at renewal if you change service provider.
Why it matters: it changes your negotiating position at renewal and your freedom to replace the implementer without reopening the licences too.
How to judge the answers
| Type of answer | What it indicates | How to proceed |
|---|---|---|
| Describes a similar case, with limits, risks and results | Concrete experience and the ability to contextualise | Ask which part transfers to your case |
| Acknowledges what is not yet known and proposes how to establish it | Transparency and method | Have the activity, timing and accountability written into the plan |
| Answers only with product features | Has not answered on process or risk | Bring the question back to data, people, output and accountability |
| Defers a lot to the analysis phase without estimating the work | Scope still immature | Ask for an explicit discovery, with output and cost |
| Promises everything with no conditions or trade-offs | Possible overstatement of scope | Ask for assumptions, dependencies, risks and priorities |
| Puts assumptions and commitments in writing | A good basis to work from | Use the material for the contract, SOW and governance |
Frequently asked
Does asking these questions create friction with the partner?
No. A serious partner has every interest in clarifying scope, dependencies, accountability and success criteria before kickoff. Ambiguity damages both sides: the client sees unexpected costs and delays, the partner receives unplanned requests and loses trust. Clarifying upfront reduces that risk for both.
Do I have to ask all of them?
No, they are a checklist. For an initial assessment start from the problem, scope, assumptions, architecture, 24-month cost, team and metrics. For an AI or Agentforce project always add data, permissions, testing, monitoring and escalation. If the platform is already live, add the questions on technical debt, release cycle and regression.
What do I do if the answers are solid but the price is higher?
Compare partners on total cost and risk, not on day rate. A more expensive partner makes sense if they reduce unplanned dependencies, guarantee senior people at the key moments, build a maintainable architecture and leave you self-sufficient after go-live. That difference has to be visible in the written proposal, though, not promised verbally.
Related reading
- What Agentforce really costs - and when to weigh a headless alternative
- Is Agentforce worth it?
- Independent proposal review - the same questions asked of yours, with the findings ordered by risk.