IT outsourcing
Managed IT services
Continuing responsibility for a bounded scope, with agreed measures and a single point of contact.
In summary: ongoing management of applications, infrastructure or advanced support, with service level agreements, a single relationship owner and a scope of responsibility set out in writing.
The difference between a managed service and an external team is responsibility: here the provider answers for a continuing outcome, not for hours worked. That requires defining precisely what is in scope and what depends on third parties.
A service level agreement that does not distinguish what we control from what we do not is unworkable in practice, and produces arguments at the first serious incident.
What is included
According to the agreed scope.
- Management and maintenance of applications in production
- Infrastructure administration within the agreed scope
- Second and third line support on the managed systems
- Monitoring, incident management and root cause analysis
- Change management with agreed windows and procedures
- Periodic reporting on availability, incidents and capacity
- A single relationship owner, with a regular service review
What is not included
What falls outside scope by definition.
- Responsibility for third-party systems not included in scope
- Committed availability where it depends on suppliers you contract directly
- Development of new functionality, which is contracted separately
- Architecture decisions committing your technology strategy without your approval
Where it is delivered from
Usually from Poland, which shares a time zone with mainland Spain and sits inside the European Economic Area, simplifying both coordination and data handling.
For out-of-hours cover, time zones are combined rather than paying night premiums, so no team works nights in its own schedule.
Frequently asked questions
What if an incident's cause is outside your scope?
It is documented, escalated to the responsible party and does not count against the service level agreement. This distinction is worth setting in the contract, because it causes the most argument when unwritten.
How is the service measured?
Against measures agreed before starting, taken from your own monitoring tool wherever possible, so both sides look at the same source.
Can we start with a reduced scope?
That is what we recommend. A small, well-bounded scope lets the measures be calibrated on real data before expanding.
What happens when the contract ends?
Operational documentation, procedures and accumulated knowledge are handed over. The exit plan is worth including in the initial contract rather than negotiating at the end.
Want to delegate running a system?
Tell us the scope, incident volume and the service levels you need.