Propose the TO BE

We start by using the TO BE processes that were defined to determine how the service should ideally operate. What matters next is shaping the service environment that enables these processes to be executed successfully. We design for the real world: how people interact with the process, the support they need, and how all parts of the ecosystem, people, platforms, and integrations, come together.
A service model defines how a service is experienced and delivered. We consider how the process will actually be operated. Who interacts with it, and when? Where are the dependencies? What support is needed at each step? This means thinking about user journeys, handoffs, and frontline roles, not just as operators of steps, but as active participants in value delivery.

Transforming processes and technology inevitably reshapes what people do. At this stage, we examine the new workflows and systems to determine what capabilities are required, from operational know-how to technical expertise and contextual understanding.

Rather than replicate old roles within a new model, we group tasks based on commonalities, which often reveals opportunities to build more integrated, multi-skilled teams. This forms the basis for meaningful organisational redesign, identifying reporting lines and escalation routes. The goal is not just to allocate responsibilities, but to create clarity so people understand how they contribute to the broader mission, enable them to spend their time where they add the most value and provide them the tools to excel in their roles.

Example from a recent project:

Peak Signal partnered with a content owner on a transformation project aimed at revolutionising its approach to scheduling, content ingest, traffic, archive management and delivery of assets for playout, VOD and third-party takers. Following the ‘Analyse the current situation’ and ‘Identify gaps’ phases, new To Be processes were meticulously designed. This new design significantly simplified operations, reducing the number of processes while introducing a high degree of intelligent automation. 

The redesigned processes featured semi-automated scheduling, with targeted human intervention when contextual decisions or troubleshooting were required. Ingest workflows became largely automated, with manual content review primarily required when exceptions were flagged for QC or ensuring title matches. Archive management transitioned to cloud-based infrastructure, with automated population of metadata from the content originators or publishers. Crucially, automated alerting systems were integrated across all the processes, ensuring human intervention was efficiently directed only when an automated process encountered an issue or a person needed to make a decision or judgement call.

In considering the service design, the following steps were taken:

The foundational business analysis and the subsequent detailed To Be process design were instrumental in enabling this effective service design. This granular understanding of real-world operational needs and anticipated scenarios ensured that the new service model was not only comprehensive but also optimised for efficiency and effectiveness.

With newly defined ‘TO BE’ processes, team structures, and integrated technologies, the framework for supporting, maintaining and continuously improving the service must also be re-imagined. The operational dynamics have shifted; consequently, the critical points for monitoring, intervention, and governance are different. It’s no longer about managing the old pain points, but proactively addressing the new realities of a transformed service. At Peak Signal, we extend the design phase to encompass these vital supporting structures. 

This is a critical phase where we move beyond the operational ‘doing’ to establish how the service itself is managed, supported and directed. At Peak Signal, we systematically address key domains such as Change Management, Incident and Problem Management, overarching Service Management, Continuous Improvement lifecycles and strategic Prioritisation mechanisms.

A critical part of our approach here is to directly integrate the findings and address the specific gaps uncovered during the initial ‘Analyse the current situation’ phase. If, for instance, the As Is analysis revealed inefficiencies in how incidents were resolved or how improvements were identified and implemented, the design of these new governance processes explicitly targets these areas – while adapting them to cater for the updated To Be processes and team structures. Our goal isn’t to apply generic templates; it’s to build robust, practical solutions tailored to each customer’s world that solve historical challenges and fortify against future ones.

This rigorous work often informs and refines the initial service and organisational design. As we map out these governance layers, including detailing how changes are approved, how incidents are escalated and resolved, how service performance is reviewed, and how opportunities for improvement are systematically actioned, we may identify the need for new roles, refined team responsibilities, or wider organisation change to ensure clarity and accountability. This approach ensures that the final service blueprint is not only operationally sound but also managerially robust, creating a resilient and responsive service ecosystem equipped for sustained success and continuous improvement.

Conclusion

Designing the TO BE service means designing for the people who will operate it. At Peak Signal, our service designs are not only aligned to future-state workflows, they provide the blueprint to move into  execution, shaped to be delivered by real teams, in complex environments. Because service transformation only works when people are supported to succeed.

In our next article, we examine the art of delivering the TO BE processes, from blueprint to reality