Managed software operations scope: what the provider runs, when, and how you leave

OutsourcingVN is operated by Netbase JSC, which sells managed operations, so this is a supplier describing the contract it would want to sign with you. The structure applies to any provider. It draws on a cloud ERP engagement where Netbase has worked as offshore development and managing partner since 2020.

What does managed operations actually cover?

Managed operations is the continuing work of keeping a live system useful: watching it, patching it, restoring it, answering users and making small changes safely. It sits between two other arrangements. A project delivers a defined change and ends. Staff augmentation supplies people whom the buyer directs. Under managed operations the provider takes responsibility for an agreed outcome within an agreed boundary, and the buyer keeps ownership and the final say on business priorities.

Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options. Knowing which of those you are buying matters more than the label on the contract, because each one puts the responsibility for a missed alert in a different place.

Which elements must the scope name?

A scope is strong when a new person on either side could read it and route a request correctly without asking anyone.

How do you set objectives without inventing an SLA?

Google's Site Reliability Engineering book separates three terms. An indicator is a measured quantity, such as how long a checkout request takes. An objective is a target for that indicator. An agreement adds consequences when the objective is missed. The distinction matters in a contract: an objective written before anyone has measured the system is a guess, and attaching consequences to a guess produces disputes rather than reliability.

Start with indicators on the journeys the business feels, for example "orders placed in the storefront reach the warehouse system before the next picking run". Measure them for a period under the new provider, agree objectives from what the measurement shows, and only then decide whether any objective needs contractual consequences. The reliability and incident readiness guide covers how alerts and runbooks support those objectives.

What does coverage look like with a Hanoi-based team?

The Hanoi office works Monday to Saturday, 9:00-18:15 Vietnam time (UTC+7), and support coverage follows those days. For a European buyer that window covers the European morning; for a buyer in the Americas it falls mostly overnight, which suits scheduled maintenance and next-morning fixes but not live incident response during the buyer's own trading day. Any cover beyond those days and hours is agreed per engagement and written into the scope before the business relies on it. Design every critical journey so that a failure outside coverage stops in a safe state and raises an alert to a named person.

Worked scenario: routing requests for a dealer ordering portal

A manufacturer runs a dealer ordering portal connected to its ERP. After a takeover, it agrees a managed operations scope. In the first weeks, four requests arrive.

The last row is the one that usually goes wrong. An API migration disguised as maintenance consumes the support capacity for weeks and hides its cost.

What does a long-running engagement teach about scope?

Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS for a US client (not named). Phase 1, from 2020 to 2023 and aimed at agency SMEs, covers CRM, real-time messaging, HR, knowledge base, custom fields and workflows, work and project management, and API integrations, on a stack of React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. The retail phase 2 was planned work when the profile was written and is not presented as delivered.

A system of that breadth cannot be run under a one-line scope: every module has its own users, data and failure behaviour. Netbase's delivery lifecycle runs through discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; and ongoing support, so operations is planned as a stage rather than bolted on.

See the multi-tenant cloud ERP SaaS platform record

Which questions should you ask a managed-operations provider?

• Which systems and request types are in scope? Expect a named list and a route for each type, not a general promise.
• What are your coverage days and hours? Expect a written window with its time zone, and a plan for alerts outside it.
• How will objectives be set? A good answer proposes measuring first and agreeing targets afterwards.
• Who approves a production change? Look for a named approver on the buyer's side, acceptance checks and a rollback step.
• Who owns what the operations team builds or changes? For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred.
• How is operational access controlled? At Netbase, security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
• What will the monthly report show? Objectives against target, incidents with causes and open risks, not a ticket count alone.
• How do we leave? Expect a notice period, a named artefact list and a handover rehearsal.

What usually goes wrong with managed operations scope?

• A scope that says "everything". Signal: disputes about whether a request is covered. Owner: the buyer's service owner, who narrows the system list.
• Objectives copied from a template. Signal: targets met every month while users still complain. Owner: both sides, who re-anchor objectives on business journeys.
• Changes without approval. Signal: production changes nobody on the buyer side can explain. Owner: the buyer's product owner, who enforces the change route.
• Reports that count tickets. Signal: volume goes up and nobody knows whether the system is better. Owner: the provider, who reports causes and trends.
• Project work hidden in support. Signal: "small changes" that run for weeks. Owner: the buyer, who moves them into a scoped project.
• An untested exit. Signal: nobody knows which accounts the provider holds. Owner: the buyer, who keeps the inventory current.

How this guide is sourced and where it stops

This guide draws on the service-level terms in Google's Site Reliability Engineering book and on Netbase records approved in the OutsourcingVN claim register: the cloud ERP engagement, delivery options, office coverage, the review rhythm, the delivery lifecycle, IP ownership and security practices. The methodology explains how those records are sourced. Netbase publishes no standard response-time commitment or contractual service level; those terms are agreed per engagement, so this page gives the structure of a scope rather than its numbers.

Put your operating boundary in writing

Bring the list of systems, a month of incident and ticket history, and the name of the person who approves production changes. Managed Operations is the service route for agreeing this scope, and the software takeover and maintenance guide covers the control checks that come first.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your system list and current support arrangement, and a person will reply with the questions a scope would need answered.

Related services and solutions