Fixed monthly commitment
Shared core + specialist capacity
application
& data
Proposed capacity · fee and coverage hours to be agreed
A working example of the pattern also used for One CRM and other applications.
Sandvik service-desk and MyPages support teams described the typical intake, business-desk and specialist-escalation pattern. CSP identifies One CRM as another example of that broad model. Exact routing remains application-specific; known catalog requests may route directly. The business desk can resolve cases within its capability, while changes follow assessment and prioritisation.
Illustrative requests. Support restores intended behaviour; development adds capability.
| Business desk | Logged incidents | Avg. resolution days | Avg. business resolution days |
|---|---|---|---|
| MyPages | 174 | 5 | 1 |
| CRM | 31 | 36 | 8 |
| ERP | 235 | 10 | 2 |
Plan for potentially intensive support in year one across the new application estate.
Sandvik service reporting provides the July benchmarks. CRM is shown under its reported business-desk label. Resolution days and business resolution days are separate measures; neither represents hands-on staff effort. Calendar and cohort definitions should be confirmed before using these figures for capacity modelling. These benchmarks illustrate existing support demand, rather than forecast volumes or service targets for the new estate.
Maria highlighted gaps in internal React/code-app coverage and some integrations requiring mixed technical skills. CSP identifies an additional gap: continued development capacity for next year has not been agreed, although CSP provides the current delivery team. Product support ownership and available capacity also need to be established. The requests shown are illustrative. Sandvik service reporting provides the operational benchmarks.
Sandvik support operators and managers highlighted constrained capacity to absorb the new estate. CSP assesses that recruiting, onboarding, product learning and establishing services will require the following year. Activities can overlap. CSP proposes sustaining support with business owners and champions during that period. This is a planning assessment for agreement with Anders, rather than an agreed internal takeover timetable.
CSP proposes the first-year hybrid model to retain delivery knowledge while Sandvik establishes internal capacity and operating arrangements. Sandvik retains service-process and product-governance accountability. Progression depends on accepted ownership, proven routing, usable knowledge and available capacity. The business decides the future balance; there is no automatic handover after one year.
CSP proposes participation in product investigation at L2 and corrective engineering at L3. Sandvik retains Product Owner accountability and responsibility for its agreed technical domains. Component ownership determines escalation boundaries for integrations, data, access and configuration. Role descriptions represent capabilities, not named-person or full-time staffing commitments.
Current CSP team + business owners
Specialists engaged as needed; defect fixes included
CSP initially · joint delivery as capacity grows
Separate backlog & development capacity
CSP proposes a business desk combining its current product capability with business owners and champions. Business participants contribute process expertise, clarification and validation; engineers perform technical corrections. Development starts with CSP and becomes joint as internal capacity grows. A gradual transfer in years two and three depends on business preference and readiness. Enhancements remain subject to prioritisation and separately reserved capacity.
Proposed capacity · fee and coverage hours to be agreed
Skill mix allocated to the budget and backlog
CSP proposes an initial support allowance of 40 person-days per month, approximately two full-time equivalents spread across the relevant capabilities. Two core support contacts cover process/application and reporting/data, with access to the original team skill pool. They coordinate requests and engage the relevant specialist. Their allocated effort and specialist work share the 40-day allowance; this is not two fully dedicated staff plus additional unlimited specialist effort. A provisional internal planning split is 24 days for business-desk work, 12 days for corrective engineering and 4 days for architecture, coordination and support preparation. These are planning allowances, not a staffing calculation derived from the incident benchmarks. The fixed monthly fee remains to be costed and agreed. Business owners and champions participate alongside CSP; the allowance describes CSP capacity.
Coverage hours, backup arrangements and response commitments remain to be agreed. The two-contact model does not yet constitute a round-the-clock on-call commitment. Agree coverage, priorities and service commitments before contracting. Check actual demand after the first three months and review quarterly. Excess demand triggers joint prioritisation or an agreed capacity adjustment, not automatic extra charges. Assess concentrated launch-period coverage separately. Access to specialists does not imply every team member is dedicated full-time.
Available development disciplines include pro-code development, low-code development, data engineering, data analysis, integration specialism and enterprise architecture. These are skills available for allocation, not six dedicated full-time positions. Seco provides an annual development budget and priorities. CSP converts these into reserved monthly capacity covering analysis, engineering, testing and releases, with detailed first-quarter planning and quarterly roadmap reviews. Development is an annual capacity commitment paid monthly, not a promise to deliver every request. Support capacity remains protected and separate. Delivery can become joint as Seco builds internal capability.
CSP proposes this operating workflow for agreement with Anders and the relevant Sandvik service and governance owners. An end user raises a request through ServiceNow. L1 performs initial handling and routes product requests to the joint CSP/business business desk. The desk investigates, classifies the need and retains coordination. Support issues are resolved directly or escalated to the relevant CSP or Sandvik specialist. A defect requiring code remains corrective support and follows appropriate testing and release controls; it is not reclassified as an enhancement merely because a developer is involved.
For a new or changed capability, the desk creates a linked change/backlog item with business need, impact and proposed acceptance criteria. Product Owner and business stakeholders review and refine scope; CSP estimates analysis, engineering, testing and release effort, dependencies and risk. The Product Owner sets priorities and the authorised budget owner approves funding within Sandvik governance. Additional investment approval is obtained where required. Items lacking approval or capacity remain pending or are refined; backlog entry alone is not a delivery commitment.
Approved work is scheduled against the separately reserved development capacity, built and tested, accepted by the business owner or champion, and released under agreed controls. Rejected acceptance returns to the delivery team for correction and validation. Release updates the linked service record, documentation and business-desk knowledge. Requester communication continues throughout; an originating incident closes only after its support outcome is validated, not merely because a change was added to the backlog. Tool configuration, review cadence, release authority and exact approval roles remain to be agreed.
ServiceNow for service handling. Jira or Azure DevOps for backlog and delivery tracking — Sandvik’s choice. Team onboarding and access required.
CSP proposes this operating workflow for agreement with Anders and the relevant Sandvik service and governance owners. An end user raises a request through ServiceNow. L1 performs initial handling and routes product requests to the joint CSP/business business desk. The desk investigates, classifies the need and retains coordination. Support issues are resolved directly or escalated to the relevant CSP or Sandvik specialist. A defect requiring code remains corrective support and follows appropriate testing and release controls; it is not reclassified as an enhancement merely because a developer is involved.
For a new or changed capability, the desk creates a linked change/backlog item with business need, impact and proposed acceptance criteria. Product Owner and business stakeholders review and refine scope; CSP estimates analysis, engineering, testing and release effort, dependencies and risk. The Product Owner sets priorities and the authorised budget owner approves funding within Sandvik governance. Additional investment approval is obtained where required. Items lacking approval or capacity remain pending or are refined; backlog entry alone is not a delivery commitment.
Approved work is scheduled against the separately reserved development capacity, built and tested, accepted by the business owner or champion, and released under agreed controls. Rejected acceptance returns to the delivery team for correction and validation. Release updates the linked service record, documentation and business-desk knowledge. Requester communication continues throughout; an originating incident closes only after its support outcome is validated, not merely because a change was added to the backlog. Sandvik Product Owner, Budget Owner and Release Authority are the agreed role labels for this proposed view. Team access must be established in ServiceNow and the chosen backlog platform. Platform labels describe work coordination, not application development technologies.
Logo sources: Cloud Solutions Partners and Sandvik media bank.