IT outsourcing
Managed services
Ongoing management of applications and infrastructure, with SLAs, monitoring and continuous improvement.
What is delivered
Severity-based SLAs, with agreed and measured penalties
Monitoring and out-of-hours incident response
Monthly reporting on availability, incidents and technical debt
What does a managed service include that a support contract does not?
Responsibility for the system's state, not only response to requests. A support contract reacts to what reaches it; a managed service monitors, detects before the user reports, and is assessed on availability rather than on tickets closed.
It also includes maintenance nobody asks for: security updates, capacity management, certificate renewal, backup review and clearing operational debt. It is invisible work when done and very visible when not, and it is the first to be deferred in a reactive model.
And it includes proposing changes. An operation seeing the same incidents every month and not proposing to change the cause is charging to treat symptoms. The monthly review looks at causes and the quarterly one can conclude the architecture needs to change.
How are service levels defined?
From business impact rather than from round numbers. A system whose downtime halts invoicing has different requirements from an internal reporting system, and applying the same level to both means overpaying for one and carrying risk on the other.
We define severity by observable effect rather than by affected component. Severity one is service unavailable to users; severity two is degradation with a workaround; severity three is a defect without immediate impact. Classifying by component produces arguments about classification during the incident.
And we separate response time from resolution time, because they are different commitments. Responding in fifteen minutes is a promise about team availability; resolving in four hours is a promise about the system, and it is only honest if the team has the access and authority to keep it.
How does out-of-hours coverage work?
By extended hours from Portugal for most European operations, covering from before the working day starts until after it ends. For many systems that is sufficient and substantially cheaper than continuous coverage.
For continuous coverage, the global network covers the European night on local daytime hours, with written handover per open incident: status, next action, owner and deadline. A prose handover is useless at three in the morning, when someone needs to know exactly what has already been tried.
There are hours nobody covers comfortably, and we say so. Between ten at night and one in the morning Lisbon time, only the teams in the Americas are on ordinary hours. It is a genuine window of thinner coverage and we prefer to show it rather than draw a continuous circle implying otherwise.
How is an existing operation transitioned?
With discovery first, observing how the system is operated today rather than how it is documented. What we almost always find is out-of-date documentation and knowledge living in the heads of two or three people, and it is that knowledge the transition has to capture.
Then by assisted operation: the current team stays accountable and we shadow, for four to eight weeks. Only then do we invert, with the current team available for escalation for a further period. Inverting directly is possible and it is how missing procedures get discovered with an incident open.
The criterion to invert is a number agreed beforehand: incidents resolved by our team without escalation, for two consecutive weeks. One good week is noise; two are a signal, and this principle repeats across all our transition models because it keeps being true.
What happens when a service level is missed?
A written root cause analysis, delivered within a set period, describing what happened, why, what was done and what changes so it does not recur. An analysis ending in human error is not an analysis but an allocation of blame, and it prevents nothing.
Contractual penalties exist and are deliberately modest, because a large penalty incentivises arguing about the incident's classification rather than resolving it. What matters more is what happens if the same cause recurs, and that is written down.
And there is a threshold beyond which the contract can be terminated at no cost to the client. We propose it by default, because a supplier unwilling to accept that threshold is saying something about the confidence it has in its own commitment.
What size of operation justifies this model?
From the point where downtime has a measurable cost and the in-house team cannot cover out of hours without wearing down the same two people. It is a threshold of risk rather than of size, and many companies cross it without noticing.
The most reliable signal is knowledge concentration. If the answer to who knows how to operate this is one name, the risk already exists and is independent of budget, and this service's first value is writing down what that person knows before they take holiday.
For small, stable systems the honest answer is frequently no. A reactive support contract covers what is needed at a fraction of the cost, and proposing a managed service there is selling a structure for a problem that does not exist.
How is the relationship governed?
With a short weekly operational meeting, a monthly review with numbers and causes, and a quarterly review that can conclude the design is wrong. The three have different functions and replacing them with one produces a meeting that handles incidents and never strategy.
And with names rather than roles in the escalation path. A path saying service manager works in normal conditions and fails at eight on a Friday evening, which is when it gets used. Names, phone numbers and a named deputy is the minimum, costs nothing and works.
Where managed services can be run from
Not every delivery model suits every service. The table shows only those that make sense for this work, with the data residency position of each.
| Model | Where | When it makes sense | Personal data |
|---|---|---|---|
| Onshore Portugal | Lisbon, Porto, Braga, Coimbra, Aveiro, Faro, Funchal and Ponta Delgada | When data cannot leave the EEA, or when the end customer is Portuguese | Stay inside the EEA. No transfer. |
| Nearshore in Portugal | Lisbon and Porto, for foreign buyers | When you need a multilingual European base without incorporating | Stay inside the EEA. No transfer. |
| Global network | Uzbekistan, the Philippines, Poland, the Dominican Republic, Mexico, Colombia, Turkiye and Africa | When you need continuous cover, specific languages or the lowest cost | Poland is inside the EEA. The others require standard contractual clauses. |
The data column describes the applicable framework and is not legal advice. The detail is in international data transfers.
Related services
- Software developmentProduct and project teams for web, mobile and backend applications, working inside your processes.
- Cloud and DevOpsMigration, delivery automation, infrastructure as code and cloud cost control.
- CybersecurityMonitoring, incident response, vulnerability management and compliance support.
- HelpdeskIT support for employees, by ticket, phone and on site, in Portuguese and English.
Frequently asked questions
What is the difference from a support contract?
Responsibility for the system's state is ours, and we are assessed on availability rather than tickets closed.
How are service levels defined?
From business impact, with severity by observable effect and response separated from resolution.
Do you cover around the clock?
We do, with the global network on local daytime hours. We also say which hours have thinner coverage.
What happens if you miss a service level?
A written root cause analysis within a set period, a modest contractual penalty, and a termination threshold at no cost.
How is the current operation transitioned?
Discovery, assisted operation for four to eight weeks, and inversion against a criterion agreed beforehand.
Do you propose changes or only operate?
We propose. An operation seeing the same incidents monthly and not proposing to change the cause is charging to treat symptoms.
Does it suit a small, stable system?
Frequently not, and we say so. A reactive support contract covers what is needed at a fraction of the cost.
How do we know we need this?
If the answer to who knows how to operate this is one name, the risk already exists and is independent of budget.
Let us look at the numbers for your case
Tell us which processes you want to outsource, in which languages and at what volume. We come back with a euro estimate and an operating design, with no commitment.
We reply within 6 hours on working days. If you would rather write: info@corpshore.solutions