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.

Replacing it with Generative AI for Financial Services capability was not the hard part. Deciding what it is allowed to do was.

The failure mode changed completely

Our old system failed visibly.

Ask something outside its eleven intents and it said it did not understand. Customers were frustrated and nobody was misled.

The replacement answers anything, fluently, including questions it should not answer. That is a different problem and it needs different controls.

The history of conversational AI explains the shift. Systems from ELIZA in the mid 1960s through the intent based era of the 2010s could only follow paths somebody had defined. Models built on the transformer architecture published in 2017 removed that boundary, and with it the honest failure that came from it.

Separate answering from acting

The distinction that structures everything.

Answering a question is reversible. A wrong answer can be corrected, and a customer who acts on it has usually not acted irreversibly.

Acting on an account is not reversible in the same way. Moving money, changing a limit, cancelling a product, or updating a record creates something that has to be undone.

Our Generative AI for Financial Services system answers. It does not act. Every account action is a handover to a person, and that boundary is enforced in the integration rather than in instructions.

Ground everything and show the source

Fluency is not accuracy.

Every answer comes from our published material, with a link to the page it drew from. Where nothing relevant exists, it says so and offers a person.

Customers click those sources more than we expected. Showing the working increased trust measurably, and it means a wrong answer is discoverable rather than invisible.

Make the handover good

The part most implementations neglect.

When a customer asks for a person, they get one, immediately, with the conversation history attached so they do not repeat themselves.

Our old system made leaving it difficult, which is why customers typed agent first. Making the exit easy reduced how often people used it, because they stopped feeling trapped.

Decide what it will never discuss

A written list, enforced technically.

Complaints, financial difficulty, bereavement, suspected fraud, and anything suggesting vulnerability go straight to a person. The system does not attempt an answer and does not ask qualifying questions first.

That list was written with our vulnerable customers team. It is the control I would be least willing to give up.

Measure refusal as a success

Our scorecard counts four things.

Questions answered without a person. Questions correctly handed over. How often a customer returns within a day with the same question. And how often the system answered something on the never list.

That last number is zero and is checked every month. Containment rate alone would reward a system that answers everything regardless.

Connect it to the records carefully

Personalised answers need reach, and reach needs controls.

Our Enterprise Application Integration Services work provides the customer view, with permissions inherited rather than bypassed and every retrieval logged. The system can see what the authenticated customer could see and nothing more.

Before authentication it answers only from public material. That separation is absolute and it is where most of the design effort went.

Write the tone down, then test it

Fluency without direction produces a voice nobody chose.

Ours is defined in writing. Plain language, no financial jargon without explanation, no false cheerfulness, and never apologetic about applying a rule correctly.

We test against it. A sample of conversations is reviewed each week against the written tone, and prompts are adjusted where the output drifts.

Generative AI for Financial Services deployments that leave tone to the model will get whatever the model defaults to, which is usually several registers at once.

Keep a person accountable for it

Not a committee.

One named person owns the system, reviews sampled conversations weekly, receives the scorecard, and can disable it within minutes.

That weekly sampling has found things no metric reported. A phrasing that was technically correct and read as dismissive. A journey where the handover happened one step too late.

What we required before launch

●        Answering only, with account actions handed to a person.

●        Grounded responses with sources shown.

●        An immediate handover with history attached.

●        A written list of topics it never attempts.

●        Public material only before authentication.

●        Logged retrieval with inherited permissions.

●        A named owner sampling conversations weekly.

Common questions

Does it need a separate knowledge base?

No, and it needs a current one. Ours answers from published material, kept current by the team that writes it rather than by a copy nobody updates.

What containment rate is realistic?

Ours handles under half, deliberately. Pushing it higher would mean answering things that should reach a person.

Should it ever act on an account?

Not in our design. Generative AI for Financial Services can prepare an action for a person to approve, and the approval is the control.

Does this need its own governance?

It does. Generative AI for Financial Services in a customer channel carries conduct obligations that an internal drafting tool does not.

How do you handle vulnerability?

A written list of topics that route straight to a person, agreed with the team that specialises in it, enforced technically.

How is the customer view supplied?

Through our Enterprise Application Integration Services layer, with permissions inherited and every retrieval logged. Before authentication it sees only public material.

Was the old chatbot worse?

It was more limited and more honest about it. The new one is better and needs considerably more governance to stay that way.

What changed for customers

Fewer people type agent immediately, and the ones who need a person reach one faster.

The capability improvement was the easy part. What took the time was deciding what it would refuse to do, and building those refusals into the integration rather than into a prompt that a clever question could talk around.

The calendar does not move

The dates are known years in advance.

Beta in June. Release in September. Store requirements updated within months. Devices updating within weeks, far faster than any other platform.

Teams that treat this as a surprise are surprised annually. We now plan a June block for beta testing and a September block for release work before the year's roadmap is set.

Most users update quickly

This is what makes iOS App Development different from the other platform.

Within two months of a release, the majority of our users are on the new version. That cuts both ways. Problems reach most of your users quickly, and so do new capabilities.

It also means supporting old versions is less necessary than teams assume. We support the current version and the two before it, which covers nearly everyone.

Test on the beta in June, not the release in September

The habit that removed our annual firefight.

Our five main journeys are tested on the first public beta and on each subsequent one. Defects found in June are reported to Apple and designed around with three months in hand.

The year we skipped this, a permissions change broke our photo upload for the first ten days of the release. We found out from reviews.

Watch for the deprecations, not the features

The announcements that matter are rarely the headline ones.

Each release removes or restricts something. Background execution rules tighten, a privacy prompt is added, an interface element behaves differently, or an older framework is marked for removal.

We read the deprecation notes carefully in June and schedule the work. Shiny new capabilities can wait. Things that will stop working cannot.

Reuse the release machinery

The annual work is easier when the ordinary work is automated.

Our builds, signing, and store submission run from a pipeline rather than from anybody's laptop. In June that means testing a beta build costs almost nothing, so we do it weekly instead of once.

The devops cost savings from that automation were modest in money and large in timing. The work that used to consume a week each September now fits inside the normal routine.

Keep the dependency list short

Every library is a thing that has to be updated before you can ship.

One September we were ready except for a single dependency whose maintainer had not updated it. We waited three weeks.

We now review dependencies annually in May, remove anything we can live without, and check that the rest are actively maintained.

Keep one person watching the announcements

Somebody has to read the release notes properly.

Ours is a named engineer each year, with time allocated in June. They read the deprecation notes, test the betas, and write a one page summary of what will affect us.

That page drives the summer schedule. Before we had it, each engineer read a little and assumed somebody else had read the rest.

iOS App Development rewards that kind of attention once a year far more than it rewards reacting in September.

Build submission into the schedule

Review is not instant, and rejections cost days.

Our release plan allows for a rejection and a resubmission. Privacy declarations, permission usage strings, and account deletion requirements have all caused rejections for us, all of them avoidable with a checklist.

We keep that checklist and go through it before every submission.

Measure what the release does to performance

A new operating system can change behaviour on the same hardware.

Our app reports start up time, main screen timing, and crash rate by operating system version. When a new version lands, we can see within days whether anything has moved.

That application performance management view has twice caught a regression that affected only the newest release, which no amount of pre release testing had found.

Decide what the new capabilities are worth

Every release brings features that proposals will suggest adopting.

We assess them against one question. Does this remove work for a user, or is it interesting? Most are interesting.

Two have been worth adopting in four years. Both reduced the number of steps in our main journey, and both were adopted in the following spring rather than rushed into September.

The same test applies to the AI capabilities now arriving each year. AI Agents for Business and on device assistants are only worth building against when they remove a step somebody currently takes.

Where automation helps after release

September brings a spike in support contacts.

Many are the same question about a changed permission prompt or a feature that has moved. We use AI agents for customer service automation to handle the repetitive ones, answering from our own help pages with the source shown, and passing anything account specific to a person.

It flattened our September support peak considerably. Nobody was replaced, and the harder contacts got answered sooner.

Our annual rhythm

●        May: dependency review and removal.

●        June: beta testing on the five main journeys, every beta.

●        June and July: deprecation work scheduled and started.

●        August: submission checklist, release candidate ready.

●        September: release within the first fortnight.

●        October: performance and crash review by operating system version.

Common questions

Who should own the June work?

A named engineer with time allocated. iOS App Development teams that spread it across everybody find that nobody read the deprecation notes.

How many versions should we support?

Current plus two. Ours covers over ninety five per cent of users, and supporting more costs real effort.

Is the June beta stable enough to test on?

Not for everything, and it is stable enough to find the changes that will affect you.

Can this be outsourced?

The work can. The calendar commitment cannot. iOS App Development partners will follow your schedule, so the schedule has to exist.

Do AI features belong in the annual cycle?

Treat them like any other capability. AI Agents For Business features should earn their place by removing a step, not by being new.

What causes most September problems?

Permissions and background behaviour. Both change often, and both fail quietly rather than crashing.

What changed

Our last three September releases shipped within two weeks of the operating system, with no hotfix and no review spike.

Nothing clever made that happen. We moved the work from September to June, where there is time to do it properly, and treated the Apple calendar as a fixed input rather than an annual surprise.

Answering that produced better results than any model comparison we ran.

Inside engineering. Our engineers use assistants daily for tests, routine code, and understanding unfamiliar parts of the system. Review load went up and typing went down, which is the correct trade.

Inside the product, narrowly. A summary that saves scrolling. Plain language search. Sensible defaults on a repeated action. None of it impressive and all of it reducing steps for a user.

Everything else we tried either did not survive evaluation or produced enthusiasm without measurable effect.

This is the area that surprised me most.

Generating tests from a specification works well for the obvious cases and needs review. Maintaining selectors after a design change is genuinely faster. Both are real time savings.

What changed more is what we test. A system whose output varies between runs cannot be asserted with a pass or fail check.

Our test automation services partner had to build something different. Standard test automation services assume a deterministic answer. A scored evaluation set with a threshold, run in the pipeline, treated as a gate. A drop in score blocks the release the way a failing test does.

That took a fortnight to build and it is the reason we can change prompts without discovering the consequences from users.

Generative AI services deployed outside your delivery process become a separate system with separate rules, and that is how estates fragment.

Ours ship through the same pipeline as everything else. Same review, same environments, same release process, with two additions.

The evaluation set runs as a gate. And token usage is recorded per change, so a prompt edit that improves answers slightly and doubles cost gets discussed rather than merged quietly.

Teams engaging devops consulting for SaaS products should raise this specifically. The tooling question is whether your pipeline can run a scored evaluation and act on the result, which many cannot without work.

Our first attempt looked for places to apply the technology. That produced a list and very little else.

The second looked at where our teams already lost time. Writing tests. Reading long case histories. Searching for something in documentation nobody had structured.

Three of those became features. The list from the first attempt produced none.

Generative AI services deliver most when pointed at a task somebody already does repeatedly, rather than at a capability somebody wants to demonstrate.

An answer is a product of the model, the prompt, and the retrieved content.

All three are versioned and pinned. When any moves, we run the evaluation set against both and look at what changed.

We learned this when a provider updated a model underneath us and our answers shifted with no deployment on our side. Nothing had broken. Nothing alerted. Quality had simply moved.

The failure I have seen most often in other organisations.

A generative feature is built by whoever was enthusiastic, ships, and then degrades slowly because nobody is watching the right signals. It does not fail. Retrieval quality drops, latency creeps, refusal rates move.

Ours has a named owner per feature, the same as any service. They watch grounding rate, validity, latency at the tail, and cost per outcome.

Without that, generative AI services produce a demonstration that becomes a liability on roughly a nine month cycle.

●      What task does this replace, and how long does it take today?

●      Can a reviewer check the output in under a minute?

●      What happens if it is wrong and nobody notices?

●      What does it cost per successful outcome at expected volume?

●      Who owns it after launch, by name?

The third question does most of the work. It separates a summary that wastes five minutes from a record change nobody catches for a month.

Who should scope this?

The team that owns the process, with engineering. Generative AI services scoped by a technology function alone tend to answer engineering questions rather than the ones the business asked.

Build or buy?

Buy the models and the plumbing. Build the workflows and the connectors to your own systems. The workflow is where both the value and the risk live.

Where does the delivery tooling need to change?

Two places. A scored evaluation gate, and cost recorded per change. Teams buying devops consulting for SaaS should ask about both specifically.

How do we test something non deterministic?

Scored evaluation rather than assertion. Your test automation services partner should be able to build that, and many have not been asked to yet.

Should this sit with a separate team?

Not permanently. A central team for the shared platform and the controls, with product teams owning their own features, has worked better for us than either extreme.

What is the most common mistake?

Treating it as a model project. Generative AI services are systems work with a model inside them, and teams who understand that ship sooner.

The cost nobody puts in the business case.

Reviewing a sample of output monthly is somebody's standing job. So is revalidating when a model, prompt, or document set changes.

That is an operational cost, not a project one. Any proposal presenting generative AI services as an implementation with an end date has left it out.

We fund it annually, like audit, and it is the reason our features still work rather than having quietly degraded.

We stopped asking what we could build with this and started asking where in our delivery process it changes something.

That produced two answers inside engineering, three inside the product, and a much longer list of things we decided not to do.

It also made the ownership obvious, which is the part that determines whether any of it still works a year later.