Go-live is the start of the platform's life. Most of the cost comes after.

Support is reactive: your team owns the platform and escalates to us when it is stuck. Managed services is standing ownership across four streams — incident and fallout response, catalog and orchestration change delivery, platform stewardship including release readiness, and the reduction work that removes the causes of recurring tickets. The fourth stream is what actually separates the two. A support contract is measured by how fast tickets close, which creates no incentive for fewer of them to arrive; a managed service should report ticket volume as a trend it is driving down, with protected capacity to do that work.

Yes, and it is a significant share of what we do. Onboarding takes longer — typically two to four weeks — because we have to document what exists, recover whatever design rationale is still recoverable, build the runbooks, and establish a baseline for flow-through, fallout and cycle time. That period is usually the most valuable part of the first year, because inherited platforms almost always contain extensions nobody can explain and recurring incidents nobody has traced to a cause. We produce a findings summary at the end of onboarding, including anything we think needs fixing before it becomes an incident.

They are set in the service definition we agree with you, sized to your order volumes, business hours and the commercial impact of each incident class — not published as a generic figure. We deliberately do not put example numbers on this page, because a response target that has not been sized against your actual platform is decoration rather than a commitment. What we will agree is coverage hours, incident classification, response and resolution targets per class, the escalation path, and the split of capacity between incidents, change and reduction work.

Salesforce ships platform releases on a published schedule, with preview environments available ahead of general availability. We test against those previews before each release reaches your production org, identify what changes in behaviour, and produce a remediation plan while there is still time to act on it. Without this, each release is discovered in production, usually by a user and usually at a bad moment. The regression suite built during implementation is what makes this affordable to run every cycle rather than a project each time.

It can, and that is a real failure mode we design against rather than dismiss. Enablement, paired working and deliberate handover of steady-state activities are part of the service, and the co-managed model exists specifically for operators who want to grow internal capability while covering the gap. We will tell you which model we think fits, including when that means recommending a smaller engagement — selling a fully managed service to an operator who actually wants internal ownership produces an unhappy client in year two.

The subject matter, and therefore the people. Order fallout is not a defect queue: triaging it needs someone who understands order decomposition, orchestration plans and how the fulfilment systems behave when they fail. A catalog release is not a routine config change: it can alter what every channel is able to sell and what the billing platform will charge. A generalist Salesforce support desk will handle your access requests and page layouts perfectly well, and will route the telecom-specific incidents — which are the expensive ones — to somebody else.

That is a planned transition, and the co-managed model is usually the route to it. Runbooks, documentation and the knowledge base are maintained as service deliverables rather than as internal notes, so they transfer. We hand back steady-state activities in stages as your team's capability grows, with paired working through each transition, and the agreement shrinks to match. We would rather run a smaller engagement for a long time than a large one that ends in a difficult separation.