Phase 2 of an Enterprise Program Across Sales, Service and CPQ

#The starting position

Large Salesforce programs are rarely delivered in one go. A first phase typically puts a cloud into use and proves the platform. The second phase is where the business asks the harder question: how do our clouds work together as one process?

The business in this engagement sells complex B2B systems. By the time Phase 2 began, it had Salesforce in use and a clear ambition for the next step. Selling, quoting and customer service needed to work as a single process. Sales teams needed to produce accurate quotes based on the company's product and pricing rules. Service teams needed to support customers knowing exactly what they had bought and on what terms. And leadership wanted renewals and expansion to come from a joined-up view of each customer instead of from separate teams with separate information.

Phase 2 was substantial: about 960 project hours spanning Sales Cloud, Service Cloud and Salesforce CPQ, with live users, existing data and existing customizations that had to keep working throughout.

#What we delivered

01 Architecture and solution design

Our architects led the solution design for the phase. That meant deciding how the three clouds would share data, where each process would start and end, which records would carry information from one stage to the next, and how existing customizations from Phase 1 would be extended rather than duplicated.

02 CPQ connected to the selling process

Salesforce CPQ was configured to turn opportunities into accurate, rule-based quotes. Product and pricing rules ensure every representative prices the same way, and the quote connects back to the opportunity so the pipeline reflects real commercial terms.

03 Cross-cloud processes between sales and service

The central work of the phase was the hand-off between selling and serving. Cross-cloud processes carry the account, the products sold and the commercial context through to Service Cloud, so service agents work with the information the sale created.

04 Configuration and development

The design was delivered through a mix of configuration and development across all three clouds, using declarative tools where they were sufficient and code where the process needed it.

05 Testing, release and change management

Because the org was live, every change was tested against existing processes as well as new ones and released in a controlled way. Stakeholder coordination and change management ran throughout, so the teams affected understood what was changing in how they worked, and why.

#Why the second phase is the harder one

A first phase has the advantage of a clean slate. A second phase has to live with every decision the first one made, while adding the complexity of making several clouds agree.

Three things make it harder. First, there are real users depending on the system every day, so changes must be released without disrupting them. Second, data already exists, created under the first phase's assumptions, and the new processes have to work with it or improve it safely. Third, the value of Phase 2 sits almost entirely in the hand-offs between clouds, which are exactly the places where small design mistakes create large problems: a product that does not carry from quote to service, or a term that is lost between the opportunity and the case.

That is why the architecture work matters so much. On a program of roughly 960 hours, an extra week spent getting the data flow right at the start costs far less than the rework that a poor decision would cause across three clouds later.

#Where quoting meets service

The connection between CPQ and Service Cloud is easy to underestimate. Quoting is usually thought of as a sales tool, and service as a separate department. In practice, the quote is the clearest statement of what the customer is entitled to: the products, the quantities, the commercial terms. If that information stops at the sales team, service agents are left to reconstruct it from emails and memory.

Carrying it through gives the business two benefits. Service quality improves, because agents support the customer according to what was sold. And growth improves, because service interactions reveal when a customer is ready to renew or expand, and the information needed to act on it is already on the record.

#How we organize a phase of this size

A phase of roughly 960 hours needs more structure than a series of tickets. We organize the work around the customer process rather than around the clouds, because the clouds are only a means to an end.

Workstreams by process stage. Selling, quoting, the sales-to-service hand-off and service each get a defined owner on the business side and a clear set of requirements. The architects hold the connections between them.

A design authority. Decisions that affected more than one cloud, such as which object carries a product from quote to service or how an existing Phase 1 customization would be extended, are made once, documented and applied consistently. That prevents different teams from solving the same problem in different ways.

Build in increments. Configuration and development are delivered in increments that can be demonstrated to the business and tested on their own, so feedback arrives early and problems are small when they are found.

Testing at three levels. Each increment is tested in isolation, then as part of the end-to-end process across clouds, then against existing processes to confirm nothing has regressed.

Release planning with the business. Release dates are agreed with the teams affected, with communication and training planned around them, so users knew what was coming and what to do differently.

This structure is what allows a multi-cloud phase to be delivered without the live org becoming unstable, and it is the same structure we use for enterprise programs today.

#How we delivered it, end to end

Delivered by our architects. This program was led by members of the SynconAI team during earlier enterprise delivery work, and the lessons from it shape how we run multi-cloud programs today.

Design the flows first. Data flow between the three clouds was agreed before configuration began.

Extend, do not duplicate. Phase 1 work was built on wherever it was sound, to avoid two ways of doing the same thing.

Test against what exists. Regression testing of existing processes ran alongside testing of the new ones.

Release in controlled steps. Changes reached users in planned releases with stakeholder communication.

Bring people along. Change management ran for the whole phase, not just at go-live.

#The decisions that mattered

Treat hand-offs as the product. The success of the phase was measured by how well information moved between clouds.

Rules over discretion in quoting. Product and pricing rules in CPQ made quotes consistent and the downstream data reliable.

Architecture leadership throughout. Keeping the same architects accountable from design to release prevented the drift that happens when design and delivery are separated.

#What changed

#What we would tell an enterprise planning Phase 2

Assume that the value is in the connections between your clouds, and design those first. Make the quote the authoritative record of what the customer bought, and make sure it reaches service. Test what already works as carefully as what is new, and keep the same architects accountable from design to release. A second phase done this way turns several Salesforce clouds into one customer process.