Service Transition Lead, Contact Centre

Job#: 3055926

Job Description:

Location: Toronto, hybrid. Minimum two days per week on site, with additional on-site presence expected during workshop and working session periods

Duration: 6 months, with possible extension, starting [start date]

Pairing: Works as a two-person unit with the Operating Model and Service Transition Analyst

Exit condition: Target operating model documented and accepted by the existing operations team, service transition process established and proven through the first release, and a defined plan for the remaining releases

When this role is posted, use the title "Service Transition Lead, Contact Centre". It is the term candidates and agencies search on. The operating model scope is carried in the opening section.

Placeholders in square brackets require completion before circulation: rate, start date, and contract vehicle.

The work

A major Canadian bank is migrating its contact centre to a cloud platform across 39 lines of business and nine releases. The build is under way. What does not yet exist is the answer to how the platform gets run once it is live.

This role owns the target operating model and the service transition into live operation. There is an operations team supporting the legacy environment today, and they will run the new one. The job is to define what that means in practice, and get them there while the build is still in flight rather than after it.

This is an evolution, not a blank sheet. The team has established practices, tooling and institutional knowledge, and a model designed without them will be documented and ignored. The work is as much about the people who will operate the platform as it is about the model itself.

The role is accountable for producing the model, the artifacts and the transition. It is not accountable for operating the platform.

Deliverables

Current state and gap

● Assessment of how the legacy platform is operated today: functions, structure, processes, tooling, and where effort goes

● Gap analysis against what a cloud platform requires, expressed as capability, process, tooling and skills gaps

● Inventory of the existing ServiceNow implementation supporting the legacy platform: catalog items, request fulfilment workflows, assignment and resolver groups, CMDB records and knowledge base content, and an assessment of what carries over, what changes and what retires

● Identification of operational domains with no owner in the current team, including cloud change enablement and release, licence and capacity management, contact flow lifecycle at self-serve speed, and AI operations

Target operating model

● Target operating model covering service delivery and production support, service management, vendor and contract management, and environment and DevOps support

● Organisational design for the run state: structure, spans and layers, decision rights, and workforce planning against the release schedule

● Role evolution map showing how existing roles change, which capabilities are new, and which legacy activities retire and when

● Skills uplift and training plan mapped to named roles rather than generic profiles

● RACI across the operations team, delivery teams, vendors and the lines of business, including resolver group definition and escalation paths

● Line-of-business onboarding and offboarding as a repeatable operational service, covering access provisioning, configuration, routing and flow setup, training, hypercare and steady-state handover, run 39 times across nine releases

● Dual-run operating model for the period the team supports both platforms simultaneously, including how ServiceNow carries catalog items, assignment groups and knowledge content for both platforms side by side, and how items retire as lines of business migrate

Service transition

● Support model definition, including incident, major incident, request, change enablement, release and escalation processes for the new platform

● Service level framework covering SLAs, OLAs and underpinning supplier commitments, with the operational KPI set and reporting required to evidence them

● Service acceptance criteria and go-live readiness criteria applied per release, giving operations a defined gate rather than an assumed handover

● Service readiness assessments across people, process, tooling, monitoring, documentation, support model, knowledge management and supplier dependencies

● Service operations documentation and runbooks, written to the standards and tooling the existing team uses today so adoption is not a second project

● Identity and access management model: RBAC design, AD group structure, entitlement model, joiner, mover and leaver process, and periodic access attestation across all lines of business

● Monitoring and alerting model: what is monitored across platform, integration and desktop layers, thresholds, alert routing to resolver groups, dashboards, and who watches what in and out of hours

● Disaster recovery and business continuity operations: operational runbooks, failover roles and responsibilities, the test schedule and the operations team role in executing it

● Early life support and hypercare exit definition per release

● ServiceNow design for the new platform, extending the existing implementation rather than replacing it: new and amended service catalog items, request fulfilment workflows, incident and change models, assignment and resolver groups, CMDB and configuration item records, and knowledge base structure

● Transition governance and reporting into programme governance, including the transition RAID log

Resourcing and funding

● FTE model and resource sequencing showing when each capability is required against the release schedule, including dual-run load

● Run cost and resourcing model, built and owned by this role, supporting the funding submission with the build versus run split made explicit

● Sourcing recommendation across in-house, contractor and managed service options for any gap the existing team cannot absorb

Handover

● Knowledge management plan, including the ServiceNow knowledge base structure, and knowledge transfer sessions with named receivers in the existing team for each function

● Formal service acceptance from operations leadership that the model is understood and owned

How the role works

Embedded with the delivery team rather than consulting from the outside. That means sitting in design and architecture sessions and raising the operational consequence of a decision while it can still be changed, holding a seat in design governance, and working with procurement and vendor management on the commercial arrangements the run model depends on.

Spends real time with the existing operations team, because a model designed without them will be documented and ignored.

Working sessions are run in person by design, because the model is decided in the room rather than through document review cycles. Expect heavier on-site weeks when sessions are scheduled.

Paired with a dedicated analyst who handles artifact production and session support, so this role stays on the decisions and the stakeholders.

Experience required

● 10+ years in technology operations, service transition or service delivery

● Has led service transition through at least one enterprise cloud platform go-live, with accountability for service acceptance criteria and operational readiness

● Has taken a new platform into an incumbent operations team before, and knows that the hard part is the people and the politics, not the process maps. Greenfield operating model design alone is not sufficient

● Hands-on operational experience with a cloud contact centre platform at enterprise scale. Genesys Cloud strongly preferred, and Verint experience across workforce management, quality management or recording is a strong advantage

● Regulated environment experience, with working knowledge of audit, risk and control expectations for production change

● Strong command of ITIL Service Transition, Service Validation and Testing, Change Enablement, Service Acceptance and Knowledge Management

● Hands-on ServiceNow experience covering service catalog, assignment and resolver groups, incident and change workflows, CMDB records and knowledge base. ServiceNow is already in use for the legacy platform, so the work is evolving an existing implementation through a platform change rather than standing a new one up

● Builds the run cost and resourcing model personally. Strong Excel modelling, and demonstrated ability to defend a cost model in a funding review

● Comfort operating inside a multi-vendor delivery model alongside a systems integrator, managing supplier dependencies through transition

Also useful

● Working knowledge across CRM integration, telephony and carrier operations, workforce management and quality management

● Exposure to conversational AI operations in a customer-facing setting

● ITIL certification

● Operating model or organisational design experience in a contact centre setting

Success criteria

● Every release from the point of engagement has service acceptance criteria applied before go-live

● The existing operations team is absorbing accountability on the migration schedule, with the model proven through at least one release rather than left as a document

● A measurable reduction in integrator support dependency across the releases covered by the engagement, with the trajectory for later releases evidenced

● Skills uplift plan funded and underway, with named people against named capabilities

● Every operational function has a named owner by the end of the engagement, with no domain left to be discovered later

Out of scope

This role does not carry production service accountability, does not manage the operations team as a line function, and does not backfill delivery roles. Where an operational gap is identified, the deliverable is the design and the transition, not the ongoing execution. This is not a run leadership seat.

Why this role is worth taking

Most operating model work is either strategy that never meets an operations team, or service transition on a single application. This is both, at scale, with the authority to shape design decisions rather than inherit them. Cloud contact centre migrations of this size are uncommon, and the seat that spans design, governance, procurement and transition is rarer still.

Apex pay scales are determined by role, experience, skill set, and location. For this new position, the estimated hourly range is provided below as a guideline; however, total compensation may vary based on individual circumstances.

Hourly Range: $$

Everforth Apex is a world-class IT services company that serves thousands of clients across the globe. When you join Everforth Apex, you become part of a team that values innovation, collaboration, and continuous learning. We offer quality career resources, training, certifications, development opportunities, and a comprehensive benefits package. Our commitment to excellence is reflected in many awards, including ClearlyRateds Best of Staffing® in Talent Satisfaction in the United States and Great Place to Work® in the United Kingdom and Mexico.

Everforth Apex Benefits Overview: In terms of professional development, Everforth Apex hosts an on-demand training program, provides access to certification prep and a library of technical and leadership courses/books/seminars once you have 6+ months of tenure, and certification discounts and other perks to associations that include CompTIA and IIBA.