Turning Salesforce Go-Live into Continuous Platform Improvement

#The problem, as it actually presented

The brief was for support. What the organisation needed was an operating model, and the gap between those two words is where most post-implementation money goes to die.

The shape is familiar. A funded implementation delivers a working org on a deadline. The partner demobilises. The programme team, who were already at capacity before they became the accidental owners of a CRM, inherit a platform with no administrator, no backlog and no route for anything to change. Requests arrive anyway, because users have just been trained to expect that the system can do things.

Within a month the requests are going to whoever answered last time. Within a quarter there is a spreadsheet of outstanding items nobody has ranked, several of which are the same item written by different people. Nothing is broken enough to escalate and nothing is improving.

#What the first ninety days actually contain

The assumption going in is that early volume is defects. It is not, and building the service around that assumption is the first expensive mistake.

Sorted honestly, most of what arrives in the first ninety days is design feedback. The field is on the wrong screen for the way the team really works. The stage name means something different to the fundraising side than it did in the workshop. The form asks for information the caller does not have at the point they are asked for it. None of that is a fault. All of it is a decision meeting reality for the first time, which is the earliest anyone could have learned it.

A second category is training, and it is larger than anybody admits. Someone was shown the process once, three weeks before go-live, alongside eleven other things.

A third, genuinely smaller, is defects: the automation that fails on a record type nobody tested, the integration that times out on the monthly batch.

Treating all three as one queue is how organisations end up paying to close the same ticket repeatedly. The design feedback gets patched rather than decided, the training gaps get answered one person at a time forever, and the real defects sit behind both.

#Triage that separates three different things

So the first thing designed was not a service level. It was the classification.

A break is something that used to work and no longer does, or something that never worked as specified. It has a fix, it has a cause, and the cause goes on a log that gets read.

A request is a change to what the system does. It does not get fixed. It gets written down, costed roughly, and put on a backlog to be ranked against everything else. The important part is that a request is never quietly implemented because it was small and the person asking was persistent.

A training gap is the system behaving as designed and the user not knowing that. The response is not a change to the org. It is an answer, plus a note, and when the same note appears four times it becomes either a documentation task or evidence that the design is wrong, which returns it to the second category.

The classification is proposed by whoever picks up the item and is visible to the client, who can overturn any of it. That visibility is the point. A supplier that classifies privately can quietly reclassify awkward design problems as training, and nobody would ever see it happen.

#The release cadence

Changes land on a fixed rhythm rather than whenever they are finished. Everything except a genuine break waits for the window.

This is unpopular for about two months and then becomes the thing people rely on. A predictable window means users know when to expect the system to look different, training can be attached to it, and a change can be held back without anybody treating it as a failure. Continuous deployment into an org whose users are volunteers and part-time staff is not a kindness.

The cadence also has to absorb the three Salesforce releases a year, which arrive whether or not anyone is ready. That work is scheduled, not reactive: a short session in each preview window to work out what actually changes underneath this org, which is a very small subset of what is announced. The routine for that is written up in our article on triaging release notes in thirty minutes, and the discipline it describes is what stops three predictable events a year from behaving like three surprises.

#Prioritisation the client controls

The backlog is ordered by the client. Not advised on, ordered.

Each item carries a rough cost and a note on what happens if it is not done, both written by the supplier, because that is a supplier skill. The ranking is done by the internal owner in a short monthly call. The supplier is allowed to argue for an item and is expected to say plainly when a request is a bad idea. It never sets the order.

This sounds procedural and it is the single most important control in the arrangement. When the supplier ranks the backlog, the roadmap becomes whatever the supplier finds tractable and profitable, and it happens without anyone intending it. The organisation still gets work delivered every month. It just stops being the work that mattered most to the organisation.

#The internal owner, even with no administrator

The organisation had no administrator and could not fund one. It still needed an owner, and those are not the same job.

The owner does not build anything. They hold the answer to what the organisation is trying to do this year, they decide the order of the backlog, they are the person users go to, and they can recognise when what came back is not what was asked for. That last capability requires some platform literacy, and building it is legitimate work for the supplier to do, which is a slightly uncomfortable thing to be paid for.

In this shape it was roughly one day a fortnight of an existing operations manager, supported deliberately rather than left to work it out. Where that role does not exist at all, the honest advice is that creating it comes before signing anything, because a supplier with no informed counterpart drifts towards whatever is easiest to invoice. That is not bad faith. It is the absence of anybody asking why the same problem has been logged nine times.

#What managed services does badly, including ours

An arrangement like this has four well-documented failure modes: ticket-shaped thinking that closes symptoms and never reaches the cause, loss of institutional memory when the supplier rotates staff, an account manager standing between the client and the person who did the work, and the structural incentive by which a supplier paid for effort does better out of an organisation that stays complicated than one that gets simplified.

We sell this service, so read that list as a disclosure rather than as balance. Each of the four has a specific counter-measure in the design above, and each counter-measure costs us something. The repeat-cause log exists to make ticket-shaped thinking visible. Written decisions with reasons, not just resolutions, exist because people leave. The person who did the work attends the monthly call, so there is nobody translating in either direction. And the standing question about what could be removed exists because nobody will otherwise ask a supplier to reduce its own future revenue.

The defence that matters is not any of those. It is that the client ranks the backlog. The decision about what gets built and why is the one thing that must never be outsourced, and every other control here is downstream of it.

#The decisions that were contested

Fixed release windows. The programme team wanted changes as soon as they were ready, which is reasonable and would have produced an org that looked different every week to a user base that logs in twice a month.

Refusing to automate the training gaps. There was pressure to build guidance into the screens for every recurring question. Some of that is worth doing. Most of it would have added permanent complexity to solve a problem that a documented answer solves for free, and complexity added for training reasons never gets removed.

Not rebuilding the parts we thought were wrong. Several implementation decisions were not how we would have done it. Raising all of them in month one would have been accurate, expensive, and would have spent trust that was needed for the things that were actually hurting. They went on the register and were ranked like everything else.

#What changes

The second-order effect is the one leaders notice. The monthly conversation stops being a report on activity and becomes an argument about priorities, which is a much better argument to be having.

#When the engagement should shrink

The measure of whether this worked is not renewal. It is that the shape of the demand changes.

Breaks fall away as causes are actually fixed. Training gaps fall away as the documentation catches up. What is left is requests, and requests are a sign of an organisation that has ideas about its platform rather than problems with it. At that point the useful thing a supplier does is specialist and occasional: an integration, a migration, a release with real risk in it.

If the volume of routine work has dropped and the retainer has not, somebody should say so. Usually the honest next step is a smaller arrangement plus a part-time administrator, and an organisation that has spent a year ranking its own backlog is now in a position to hire one and know what to ask for.

#What we would tell you before starting

Fund the year after go-live before you fund the go-live. A budget that stops at launch is not a smaller version of this; it is a decision that the org will decay, taken quietly.

Then name the internal owner, by name, before you talk to any supplier including us. If nobody can be named, that is the problem to solve first, because it defeats every version of this arrangement. An unmanaged supplier closes tickets forever and reports excellent service while doing it.

What you have to decide is not whether to buy support. It is who in your organisation is going to own the backlog, and whether you are prepared to give them the time to do it properly.