Beijer Ref strengthened its internal IT team with a defined co-managed operating model, not by replacing it
Beijer Ref had an experienced internal IT team that understood the business, supported users well and stayed close to day-to-day priorities. As the organisation grew, infrastructure, network, security and project demands began to exceed what the internal team could carry while maintaining daily operations. The issue was not internal IT capability — it was capacity, structure and the need for deeper engineering support behind the team.
Inlight IT was engaged to operate alongside the internal team, not replace it. The model separated user-facing operational support from deeper infrastructure, network and strategic delivery work, with clear accountability between both teams.
- Client
- Beijer Ref
- Industry
- Industrial operations
- Sector
- Refrigeration, HVAC and climate technology
- Environment
- A capable internal IT team carrying broadening infrastructure, network, security, cloud and project demands alongside daily operations
- Engagement type
- Co-managed IT — a defined operating model separating user-facing support from senior engineering, infrastructure, network and project delivery
- Operating model
- User and business-facing ownership stayed with internal IT; senior engineering and technical delivery sat with Inlight IT
- Outcome
- Clearer ownership and escalation between both teams, with senior engineering depth added behind the internal team rather than over it
Beijer Ref — a defined co-managed IT operating model
How senior engineering depth was added behind a capable internal IT team.
A defined operating model, not informal overflow help
The internal team kept user-facing ownership; Inlight IT carried the deeper technical layer — with clear accountability between both teams.
One defined operating model, kept current through regular alignment as the environment changed.
Defined ownership, clearer escalation, consistent technical-layer ownership, a strategic delivery path and regular alignment.
First-line triage, user relationships and day-to-day support stayed with the internal team, with a defined escalation path into Inlight IT.
Co-managed IT works best when internal IT is not the problem
In many organisations the internal team knows the users, systems, business context and operational priorities better than any external provider could.
The pressure begins when that same team is expected to handle user support, access requests, daily operations, infrastructure lifecycle, network change, cyber controls, cloud platforms and strategic projects at once.
For Beijer Ref, the role was to preserve what internal IT already did well and add senior engineering depth where the environment needed more support.
A capable internal team can still be overloaded when the operating model is unclear
As organisations grow the work becomes broader — more users, more sites, more systems, more security expectations, more cloud and more infrastructure change. The question was not whether internal IT should stay; it should. The question was how to give the business deeper engineering support without weakening the internal team's role. The answer was a clear division of responsibility.
User and business-facing ownership stayed with internal IT
The internal team retained the work that depended most on business context: user relationships, local priorities, day-to-day support, onboarding, access coordination and first-line triage. Where an issue required deeper engineering support, there was a defined escalation path into Inlight IT rather than an informal handoff.
Senior engineering and technical delivery sat with Inlight IT
Inlight IT carried the deeper technical layer: infrastructure and network engineering, security and access improvement, Microsoft 365 technical depth where required, complex escalation, project delivery, roadmap input and lifecycle planning. That gave the internal team stronger backing without weakening its role.
The issue was capacity and structure, not capability
As the organisation grew, infrastructure, network, security and project demands began to exceed what the internal team could carry while maintaining daily operations. The issue was not internal IT capability — it was capacity, structure and the need for deeper engineering support behind the team.
Internal IT had to stay — and stay strong
The question was not whether internal IT should stay; it should. The question was how to give the business deeper engineering support without weakening the internal team's role.
The model had to be defined, not informal
The model was not treated as informal overflow help. It was structured so Beijer Ref knew what each team owned and how work moved between them, with clear accountability between both teams.
Two teams, clear domains, one support rhythm
The model was built around a clear division of responsibility, defined before the pressure arrived rather than as informal overflow help.
01The engagement started by defining who owned what
Responsibilities were separated explicitly so Beijer Ref knew what internal IT owned, what Inlight IT owned and how work moved between them.
02Complex issues had a clearer escalation path
Issues that needed more than first-line support had a defined route into senior engineering, rather than landing back on an already-stretched internal team.
03The deeper technical layer gained more consistent ownership
Infrastructure, network and security work gained senior engineering ownership rather than being fitted around daily operations.
04Strategic work had a clearer delivery path
Project delivery no longer depended only on internal capacity left over after daily operations.
05The model stayed useful through regular alignment
Regular alignment kept the division of responsibility current as the environment changed.
From role clarity to operating rhythm, then into ongoing engineering support
Select a stage to trace how the model moved from role clarity to operating rhythm.
Capable internal teams are often carrying more than the operating model was designed for
As organisations grow the work becomes broader — more users, more sites, more systems, more security expectations, more cloud and more infrastructure change. The internal team knows the users, systems and business context better than any external provider could; the pressure begins when that same team is expected to carry daily operations and the deeper technical layer at once. Beijer Ref's model gave that pressure a clear path instead of relying on ad hoc overflow.
Two defined domains: user and business-facing ownership with internal IT, senior engineering and technical delivery with Inlight IT.
One support rhythm, kept current through regular alignment as the environment changed.
Five parts of the model, from defining who owned what through to regular alignment.
First-line triage stayed with the internal team, with a defined escalation path into senior engineering behind it.
A co-managed IT model that strengthened internal IT without weakening it
The model preserved what internal IT already did well and added senior engineering depth where the environment needed more support, with clear accountability between both teams.
Internal IT stayed close to the business
The internal team kept the user relationships, business context and operational presence where they mattered most.
Senior engineering depth was added behind the team
Inlight IT provided infrastructure, network, security and delivery depth without removing the internal team's role.
Responsibilities were separated clearly
Both teams gained defined domains rather than overlapping, unclear ownership.
Escalation became clearer
Complex technical issues had a defined route into senior engineering.
Infrastructure and network work had a stronger delivery path
Lifecycle and change work moved without pulling the internal team off daily operations.
Strategic projects gained capacity
Project work no longer depended only on leftover internal capacity.
The issue was never internal IT capability. The model added capacity, structure and deeper engineering support behind the team — not over it.
Clarity, not outsourcing
Internal IT preserved
The internal team's value was kept, not replaced.
Depth added behind the team
Senior engineering capability sat behind, not over, internal IT.
Defined domains
Clear ownership across user-facing and engineering work.
Clearer escalation
A defined path for complex technical issues.
Stronger delivery path
Infrastructure, network and project work kept moving.
Defined before escalation became informal
The operating model gave pressure a clear path instead of relying on ad hoc overflow.
The work connected internal IT enablement, senior engineering and operating-model definition
Operating model
6- Co-managed IT
- Operating-model definition
- Internal IT enablement
- Defined responsibilities
- Escalation path design
- Regular alignment
Infrastructure and network
6- Infrastructure engineering
- Network engineering
- Infrastructure lifecycle planning
- Network change
- Cloud platform support
- Lifecycle and change delivery
Security and Microsoft 365
6- Security & access improvement
- Cyber controls
- Access coordination
- Microsoft 365 technical depth
- Complex escalation
- Senior escalation
Delivery and support
6- Project delivery
- Roadmap input
- First-line triage (internal IT)
- Day-to-day support (internal IT)
- Onboarding and access requests
- Strategic delivery path
Need co-managed IT support that strengthens your internal team?
We add senior engineering depth alongside your internal team, scoped to defined responsibilities.
Discuss Co-Managed IT