SECO / CSP
Post-delivery operating model
Discussion proposal · For Anders
01 / Sandvik’s typical support operating model

How MyPages is supported.

A working example of the pattern also used for One CRM and other applications.

End user
Raises a request
ServiceNow / L1
Initial triage & routing
Business desk
Investigates · resolves · routes
Specialist teams
Technical diagnosis & fixes
Standard service channelBusiness knowledge + technical understandingEscalation when required
Business change requestAssessment & prioritisationDevelopment
The business desk connects the user’s problem to the right resolution.
Presenter notes & basis

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.

02 / What the new estate needs

Existing teams.
Gaps in ownership, capacity and skills.

IN PLACE

ServiceNow
& service desk

Intake · initial triage · routing
TO ESTABLISH

Product ownership
& available capacity

Someone to follow issues end to end
PARTIAL COVERAGE

Internal
specialist teams

Gaps include React and some cross-technology integrations
NOT YET AGREED

Next-year
development team

CSP builds today; future capacity is uncommitted
“The portal won’t submit.”React UI → application logic → API
“Account data is out of date.”D365 → integration → Dataverse
“The report doesn’t reconcile.”Source data → transformation → reporting
Enhancement: “Add an approval step to the portal.”Business desk → prioritised backlog → development team

Illustrative requests. Support restores intended behaviour; development adds capability.

Existing operations · July 2026Sandvik service reporting
Business deskLogged incidentsAvg. resolution daysAvg. business resolution days
MyPages17451
CRM31368
ERP235102

Plan for potentially intensive support in year one across the new application estate.

Benchmark interpretation

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.

Presenter notes & basis

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.

03 / Why a first-year bridge is needed

Deliver by mid-December.
Build support capability through next year.

CAPACITYRecruit & allocate
KNOWLEDGEOnboard & learn
OPERATIONSSet up services
ADOPTIONCommunicate & embed
Hiring takes monthsUnderstand the productsForms · queues · ownershipUsers know where to go
MID-DECEMBER
Go-live
PROPOSED PLANNING HORIZON · YEAR ONE

CSP + business owners sustain support

Internal teams build capacity and the operating arrangements
YEAR END
Review readiness
Our assessment: allow the whole of next year to establish support for this estate.
Presenter notes & basis

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.

04 / Proposed first-year bridge

Keep the builders close.
Make room for the operating model.

GO-LIVEYEAR ONE · HYBRIDREADINESS REVIEW
Product triage + corrective engineering + knowledge transfer
Service desk + specialist teams + support-process preparation
Confirm ownership · rehearse escalation · build knowledge · review capacity
Move when readyAccepted ownershipProven routingUsable knowledgeAvailable capacity
Year one is the proposed bridge. The next step depends on readiness.
Presenter notes & basis

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.

05 / Where CSP fits

One support process.
CSP participates in L2 and L3.

L1

Sandvik service desk

Intake · initial handling · routing
Existing service channel
L2

CSP product support

Process & application + reporting & data
Investigate · resolve · coordinate
L3

CSP engineering

Product defects · code · data logic
L3

Sandvik specialists

Platforms · infrastructure · D365 · integrations
CSP keeps ownership of product investigation while the right specialist works on the cause.
Presenter notes & basis

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.

06 / Joint support, evolving delivery responsibility

A shared business desk.
Two clear delivery paths.

End userServiceNow / L1
Business deskCSP + business owners / championsTriage · route · resolve where capable
SUPPORT

Restore intended behaviour

Investigate · correct · validate

Current CSP team + business owners
Specialists engaged as needed; defect fixes included

DEVELOPMENT

Add or change capability

Assess · prioritise · build

CSP initially · joint delivery as capacity grows
Separate backlog & development capacity

Year one CSP continuity + growing internal capabilityYears two-three Gradual handover if wanted and ready
Presenter notes & basis

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.

07 / CSP’s proposed year-one offer

Continuity you can plan for.
Development within your budget.

SUPPORT

Fixed monthly commitment

40person-days / month
Shared core + specialist capacity
Support ticket
Process &
application
Reporting
& data
Two core support contacts
Original team skill poolApplication · data · integration · architecture
The right specialist joins for the ticket.

Proposed capacity · fee and coverage hours to be agreed

DEVELOPMENT

Annual budget, paid monthly

1Agree annual
budget
2Reserve monthly
team capacity
3Deliver agreed
priorities
The skills behind your roadmap
Pro-code
developer
Low-code
developer
Data
engineer
Data
analyst
Integration
specialist
Enterprise
architect
Prioritised roadmap Quarterly review

Skill mix allocated to the budget and backlog

Predictable monthly spending  ·  Continuity of product knowledge
DECISION FOR ANDERSAgree the support capacity and provide a development budget envelope.
Presenter notes & basis

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.

08 / Proposed workflow from request to release

One request. A clear route
from triage to delivery.

SECO request, support and development workflowRequests enter ServiceNow and L1. Unresolved product issues reach the joint business desk at L2, then CSP or Sandvik specialists at L3. Resolved incidents return to user validation and closure. Enhancements enter a linked development backlog, refinement, estimation, approval, scheduling, build, business acceptance and release. Deferred approval returns to the backlog; failed acceptance returns to delivery. END USERL1L2L3DEVELOPMENTRequestSandvikservice deskBusiness deskCSP + businesschampionsSpecialistengineeringSeparately reservedcapacity UnresolvedResolvedResolvedNeeds specialist fixResolvedNew / changed capabilityDefer / refineApprovedNot accepted: reworkAccepted Business needIssue or enhancementServiceNow requestOne traceable service recordInitial triageInvestigate & routeProduct escalationKeep request context Business deskClassify & investigateResolution activitiesProcess, application & dataCSP / SandvikRelevant specialist fixes defect Validate with userConfirm support outcomeUpdate & closeService recordKnowledge & feedbackBusiness desk learns Code defect fixes remain support.Engineering does not imply enhancement. Linked backlog itemBusiness deskBusiness need + ticket linkReview & refineProduct Owner + businessScope + acceptance criteriaEstimateCSP delivery teamEffort + dependencies + risk Approve &prioritise?Product Owner + budget owner ScheduleAgreed capacityBuild & testCSP / joint team Business acceptanceOwner / championControlled releaseAgreed release authorityHand back to supportTicket + documentation + knowledge Backlog entry is not approval. Delivery requires funded priority and allocated capacity.
Presenter notes & basis

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.