Running Commercial Systems on One Platform

With our Salesforce Implementation Partner, our sales, service and marketing teams all work in the same platform, and for three years each of them treated it as their own system.

The result was an org that served nobody well. Here is how we run it now.

One platform, three sets of expectations

The underlying problem.

Sales wanted speed and flexibility. Service wanted reliability and clear process. Marketing wanted data nobody else had agreed to collect.

Each made changes that suited them. Over three years that produced duplicate fields, conflicting automation, and reports that disagreed about the same customer.

Decide which team owns which object

The governance that settled most arguments.

Each major object has one owning function. Sales owns opportunities. Service owns cases. Marketing owns campaign membership. The owner decides what fields exist and what they mean.

Other teams can request changes and cannot make them. That sounds restrictive and it ended a class of dispute that had been running for years.

Settle the shared records explicitly

Accounts and contacts belong to everybody, which means they belong to nobody.

We named one authoritative source per field. Contact details come from service, because they are updated during contact. Segmentation comes from marketing. Account hierarchy comes from sales.

Each team sees everything and may only write to what it owns. The disagreements about whose number was right stopped within a quarter.

Make your partner work across all three

The commercial change that mattered.

Our previous arrangement had the partner engaged by sales, which meant service and marketing requirements arrived as afterthoughts and were implemented around decisions already made.

Our Salesforce Implementation Partner now works to a single roadmap covering all three functions, with one product owner. A Salesforce Implementation Partner engaged by one team will build for that team, which is what we had before. Changes are prioritised against each other rather than by whoever commissioned the work.

Agree what happens to disputed changes

Three functions will disagree eventually.

Ours escalates to the product owner, who decides within a week, with the reasoning recorded. There is no appeal to whoever shouts loudest or pays for the work.

That mechanism has been used four times in two years. Knowing it exists has probably prevented more disputes than it has settled.

Keep the reporting definitions in one place

The most common source of mistrust.

Three teams counted active customers three ways. All three were defensible. None matched, which meant every meeting started with a reconciliation argument.

Definitions now live in one documented place, with an owner per metric. Reports read from those definitions rather than reimplementing them.

Deploy like software

Not through change sets at six in the evening.

Changes move through version control and a pipeline, with review, testing in a sandbox, and the ability to roll back.

Our pipeline is a Jenkins DevOps arrangement that handles the platform alongside our own services. A change touching both deploys as one coordinated release rather than two independent ones.

Plan around the seasonal releases

Three a year, with preview environments weeks ahead.

Our partner tests the main journeys against preview each cycle and tells us what will affect us. We schedule around it rather than being surprised.

A commercial platform that falls behind on releases eventually needs a remediation project, which is considerably more expensive than reading the notes.

Measure it with everything else

Same dashboard, same numbers.

Cycle time, change failure rate, time to restore, release frequency. Our devops KPIs cover the platform work alongside our services, which makes the comparison visible.

When platform work was reported separately, it was judged by different standards. Putting it on the same dashboard changed the conversation within two months.

Give each function a route that is fast enough

Restriction without a fast route produces workarounds.

Each function can request a change and expects a decision within a week and delivery within a sprint for anything small. That commitment is what makes the governance acceptable.

When our response time slipped to three weeks during a busy quarter, two teams started asking for direct access again. The governance held because we fixed the response time rather than the rules.

Review what nobody uses

Commercial platforms accumulate faster than most.

Campaign fields from a programme that ended. Automation for a product line discontinued two years ago. Reports built for a manager who left.

Our annual review removes what is unused, with notice to the owning function. The first pass removed several hundred fields and nobody asked for one back.

What we put in place

●        One owning function per major object.

●        An authoritative source per field on shared records.

●        A single roadmap and one product owner across all three teams.

●        Metric definitions documented once, with owners.

●        Version controlled deployment through a pipeline.

●        Preview release testing every cycle.

●        An annual removal pass with notice.

Common questions

Should each team have its own org?

Rarely. Separate orgs end the arguments and lose the shared customer view, which is usually why the platform was bought.

Should the partner cover all three functions?

Yes. A Salesforce Implementation Partner contracted to one function will deliver for that function and leave the others to work around it.

Who should be the product owner?

Somebody accountable across all three functions, not a representative of one. That appointment was the hardest part.

How should releases be coordinated?

Through one pipeline. Our Jenkins DevOps arrangement deploys the platform alongside our services, so a change touching both has one rollback plan.

How do we stop teams making changes directly?

Limit administrative access and provide a fast route for requests. Restriction without a fast route produces workarounds.

What should a partner be contracted for?

The whole platform, not one function. A partner engaged by a single team will optimise for that team, reasonably and expensively.

What Changed

One roadmap, one definition per metric, one owner per object, and an org three teams can rely on.

The platform is the same platform, and so is the Salesforce Implementation Partner. What changed is that somebody decides, the decisions are written down, and our partner works to all three functions rather than to whichever one is paying attention.