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

> An enterprise B2B business had a first phase of Salesforce live and a second phase that had to join selling, customer service and quoting into one process. Our architects led that phase: about 960 hours of architecture, design, build, testing, release and stakeholder coordination across three clouds.

- Source: https://synconai.com/case-studies/enterprise-multi-cloud-sales-service-cpq
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Delivered client engagement. The client is anonymised; the industry, products and outcomes are theirs.
- Organisation: An enterprise business-to-business systems company running a large Salesforce program across sales, customer service and quoting
- Industry: Commercial & Business Services
- Products: Sales Cloud, Service Cloud, Salesforce CPQ, Salesforce Platform, Flow, Apex
- Service: Salesforce for Large Enterprises (https://synconai.com/salesforce-for-large-enterprises)
- Reading time: 6 minutes

## In short

Our architects led Phase 2 of an enterprise Salesforce program, about 960 project hours, joining Sales Cloud, Service Cloud and Salesforce CPQ into one customer process. The work covered architecture and solution design, configuration, development, testing, release, stakeholder coordination and change management, with cross-cloud processes connecting quoting, selling and service.

## Key points

- Phase 2 is where the hand-offs live. Phase 1 usually proves each cloud; Phase 2 has to make them work as one process.
- CPQ shapes the data everything downstream depends on. The products and terms on a quote become what service supports and what renewals are based on.
- Architecture time is cheap compared with rework. On a program of this size, the decisions made in the first weeks determine the cost of every later change.
- Change management is part of delivery. A multi-cloud process changes how several teams work, and they need to be brought along deliberately.

## One customer process across three clouds

The customer process runs as a loop across three clouds. Sales Cloud manages accounts and opportunities. Salesforce CPQ turns the opportunity into a configured, priced quote using the business’s product and pricing rules. The won quote becomes the commercial basis for what the customer receives. Service Cloud handles the customer’s requests after the sale, with the account, products and commercial history visible to service agents. Service interactions in turn reveal renewal and expansion opportunities that start the loop again in Sales Cloud. Phase 2 was about making the hand-offs between these stages reliable.

### 1. Sell

- Accounts
- Opportunities
- Pipeline

The opportunity is the start of the commercial record.

### 2. Quote

- Salesforce CPQ
- Product rules
- Pricing
- Approvals

Quotes follow the rules, so every rep prices the same way.

### 3. Commit

- Won quote
- Products sold
- Commercial terms

What was sold is what service will support.

### 4. Serve

- Service Cloud cases
- Customer context
- Product history

Agents see what the customer bought and on what terms.

### 5. Grow

- Renewals
- Expansion
- New opportunities

Service insight feeds the next sale.

## 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

| Area | Before Phase 2 | After Phase 2 |
| --- | --- | --- |
| Clouds | Working largely in isolation | Sales, Service and CPQ joined in one process |
| Quoting | Dependent on individual practice | Rule-based quotes from CPQ connected to opportunities |
| Service context | Limited view of what was sold | Account, products and commercial context on the case |
| Growth signals | Spread across teams | Renewal and expansion visible from service interactions |
| Releases | Risk to live users | Tested and released in controlled steps |
| Adoption | Left to each team | Stakeholder coordination and change management throughout |

## 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.

## Questions

### What made this a Phase 2 rather than a new implementation?

The business already had Salesforce in use from an earlier phase. Phase 2 extended it across clouds and joined them, which meant working with live users, existing data and existing customizations instead of a blank org. That raises the bar for design, testing and release.

### Why does CPQ matter to customer service?

Because the quote defines what the customer bought and on what terms. When service agents can see the products and commercial terms from the quote, they can support the customer correctly and spot renewal or expansion opportunities. When they cannot, they guess.

### Would this program be built on Revenue Cloud today?

Salesforce now positions Revenue Cloud as the successor to Salesforce CPQ for new quoting implementations. The architectural lessons are the same: product and pricing rules, clean hand-offs from quote to service, and careful release management across clouds.

---

SynconAI. https://synconai.com/case-studies/enterprise-multi-cloud-sales-service-cpq