How to understand and reduce implementation risk before the customer signs

Why implementation risk is your problem, not just delivery's

When a project struggles, the customer does not blame the integrator alone. They remember who sold them the vision. Low adoption shows up at renewal, and a troubled first project makes every expansion conversation harder. Implementation risk is a pipeline risk with a delay.

It also affects whether the deal closes. Late-stage stalls often come from a quiet fear that the project will be too big, too slow or too disruptive. A buyer who cannot explain the plan to their own leadership will not sign. When you surface and address risk early, you remove the reason for that stall.

You are not expected to be a solution architect. You are expected to ask the right questions, write down the answers, and bring in the right people before the customer commits.

Scope: agree what is in phase one, and write down what is not

Scope risk is the most common cause of overruns. It starts in the sales cycle, when every exciting idea from every demo quietly becomes an expectation. By kickoff, the customer believes they are getting everything they saw.

Help the customer separate must-haves for go-live from things that can wait. Ask what has to work on the first day for the project to count as a success. Ask what they would cut if the timeline were half as long. Then write a short list of what phase one includes and what it does not, and share it with the buyer and the delivery team.

For example, a 120-person regional lender might need lead management, loan pipeline tracking and basic reporting in phase one, with borrower self-service and AI agents in phase two. Saying that out loud during the sale avoids a painful conversation three months into the project.

Data: find out how messy it is before anyone promises a date

Data migration is where timelines go to die. Customers often believe their data is cleaner than it is, and nobody checks until the project has started.

Ask where the data lives today, how many systems hold customer records, who owns data quality, and when someone last cleaned it. Ask whether there are duplicates across systems and whether there is a single ID that links them. If the customer cannot answer, that is your finding. Recommend a data assessment early, and make sure the plan includes time for cleanup and testing, not just the load itself.

If the customer is interested in AI, data matters even more. Agents and analytics depend on reliable data. The Agentforce readiness checklist at /resources/agentforce-readiness-checklist/ is a useful way to start that conversation without overclaiming what will work on day one.

• Number of source systems with customer or account records
• Rough record counts and how far back history needs to go
• Known duplicates and whether a shared identifier exists
• Who owns data quality today, by name
• Fields or objects nobody can explain

Integrations: list every connection and who owns the other side

Integrations add risk because they involve systems and people outside the Salesforce project. An ERP team with its own release schedule, a vendor that charges for API access, or a legacy system with no documentation can each delay go-live.

Build a simple integration list with the customer: each system, the direction of data, how often it must sync, and who owns that system. Ask whether the other system has a supported way to connect and whether its owner has agreed to the work. When there are many connections or complex logic, an integration platform such as MuleSoft may come up. Let the delivery team recommend the approach based on the list, rather than deciding it in a demo.

Change management: plan for the people, not just the system

A project can launch on time and still fail if people do not use it. Change risk shows up when the users were not consulted, managers do not reinforce the new process, or the old tools stay available.

Ask who will lead adoption on the customer's side and how much of their time is committed. Ask how users will be trained and what happens to the spreadsheets and old systems on go-live day. Ask which managers will run their meetings from Salesforce reports. A customer who has answers to these questions is far more likely to succeed. The common pitfalls at /resources/salesforce-implementation-mistakes/ make a good pre-read for a buyer who has not run a project like this before.

Partner selection and fixed-scope starts

Many customers have never picked a Salesforce delivery partner. You can help them run a fair process without steering them. Encourage them to ask every candidate the same questions: who will actually work on the project, what similar projects they have delivered in the same industry and size, how they handle scope changes, how they price (fixed fee, time and materials, or phased after discovery), and what happens after go-live. Ask for references they can call. The pricing guide at /resources/salesforce-consulting-pricing-guide/ helps buyers understand the cost models.

Some partners offer fixed-scope starter engagements, often called Jump Starts, for customers who want to go live on a defined core and expand later. What is included, how long it runs and what it costs vary by product and by partner, so read the scope in writing and compare it to the must-have list you built with the customer. A fixed-scope start works well when phase one is clear and modest. It works badly when it is used to make a complex project look small.

The single most useful thing you can do before signature is to bring a delivery partner into discovery, so the plan is shaped by someone who will be accountable for it. The deal desk at /salesforce-account-executives/deal-desk/ is one route to a scoped estimate on a live deal.

Talk tracks

Common mistakes

How you will know it is working

• Late-stage deals stall less often over timeline or project worries
• Customers can explain their phase one scope to their own leadership
• Delivery teams report fewer surprises at kickoff
• First renewals in your book show steady or growing use

Questions