Discover how managed services can increase efficiency and help NetSuite newbies optimize their business operations.
Most businesses decide what happens after go live somewhere around the point they are already living with the consequences. The project closes, the partner steps back, and the question of who now owns the system gets answered by default rather than by decision.
Managed services is the arrangement that answers it deliberately. This article covers what it actually includes, why the period immediately after go live is when it matters most, how to judge whether you need it, and what separates a useful arrangement from an expensive help desk.
During implementation you have a project team, defined responsibilities and someone accountable for everything working. The day after cutover, most of that disappears.
What remains is a system nobody has run in production before, users encountering their first real problems, reporting that was built to a minimum standard, and a list of things deferred to a phase two that has no date.
Meanwhile the internal people who carried the project return to the jobs they were doing before, usually with a backlog. The capacity that existed during the project does not persist after it, and that is precisely when demand for it peaks.
The result is a period where requests queue, small problems become workarounds, and the trajectory of the next three years gets set without anyone deciding it.
Arrangements vary, and the useful ones tend to include the following.
Answering the questions people have, from someone who knows your configuration rather than generic NetSuite behaviour. The response time matters more than the depth, because a question answered same day keeps someone on the system.
Users, roles, permissions, forms, fields and the continuous small configuration changes a business generates as it operates. This is the bulk of the work in most arrangements.
Building and maintaining saved searches, reports and dashboards. Almost always the largest single request category and the one where the most value is available, because reporting is usually the least complete thing at go live.
Checking that scheduled scripts run, integrations complete, and errors are noticed. A failing script is silent, which means nobody reports it, which means it fails for months.
Testing your account against the twice yearly NetSuite releases, and identifying new functionality worth adopting. Businesses without this treat releases as risk and never capture the opportunity.
Access to people who can build workflows and scripts when configuration genuinely will not reach, without commissioning a separate project each time.
Someone to ask whether a proposed change is sensible before committing to it. This is the least visible part and frequently the most valuable, because the changes not made are as consequential as the ones that are.
There is an intuition that managed services is for established users, and that a newly implemented account should be stable and need little. The opposite is closer to true.
A new account generates the most change. Configuration decisions made during the project meet reality and some need adjusting. Users discover requirements nobody anticipated. Reporting gaps become obvious once people try to actually run the business on the system.
A new account also has the least internal capability. Nobody has years of familiarity. The people who learned most during the project learned a specific slice of it, and there is no accumulated experience of how the account behaves.
And the first year sets the pattern. Whether people believe the system works for them, whether reporting is trusted, whether requests are worth raising. All of that is decided in the first months, and it is difficult to reverse later.
Being specific matters, because the general case for support is unpersuasive.
Reporting is the largest single area in most accounts, because it is almost always under built at go live and because people meet the gap with exports. Once a spreadsheet becomes the trusted version of a number, moving it back into the system is a change management problem as well as a technical one, and it gets harder the longer it runs.
Response time is the second, and it determines whether people stay on the system. The gap between somebody hitting a problem and getting help decides whether they persist or invent a workaround, and workarounds invented in the first fortnight tend to become permanent.
Proactive monitoring is the third and the least visible. Scheduled scripts failing silently, roles that have accumulated permissions they should not have, integrations that stopped and nobody noticed.
And release adoption is the fourth, since capability arrives twice a year included in what you already pay for, and businesses that never look at it accumulate a widening gap between what they buy and what they use.
A few honest questions settle this faster than a general discussion.
Where the answer to several of these is a named person who has another full time job, or nobody, the gap is real regardless of whether it has caused a problem yet.
There are three realistic options after go live, and each suits different circumstances.
Hiring an administrator gives you someone embedded in the business, present in conversations and building institutional knowledge. It costs a full salary, takes time to recruit, and carries the risk that one person holds everything. It suits businesses with enough complexity to keep someone genuinely occupied.
Engaging ad hoc means paying only for what you use. It sounds efficient and works poorly in practice, because each engagement starts with re-establishing context, response times are unpredictable, and nothing proactive ever happens. Nobody is monitoring anything between engagements.
Managed services gives you continuity without a full salary, breadth across more of the platform than one person would have, and cover during absence. It suits businesses where NetSuite matters but does not justify a dedicated hire, which is a large proportion of mid sized companies.
These combine perfectly well. Plenty of businesses run an internal administrator with an external arrangement behind them for specialist work, leave cover and second opinions.
Beyond doing the work, a good arrangement applies judgement about what work should be done at all.
The principle is solving at the lowest level that genuinely works. Configuration before declarative customisation, declarative before code. Each step down the ladder is a permanent maintenance obligation and a dependency that has to be tested at every release.
A great many requests that arrive labelled as development turn out to be configuration nobody explored, a saved search nobody built, or a training gap wearing a technology costume.
The check that catches this is asking what outcome the business actually wants rather than accepting the solution somebody has already imagined.
Applied consistently over years, that discipline is the difference between an account that stays adaptable and one that accumulates until nobody dares change it.
The practice that distinguishes sustainable support from accumulation, and the one most often absent.
Every arrangement has an intake process for new requests. Almost none have an exit process, which is why accounts only ever grow.
An annual review asking of each customisation whether it is still used, whether the need still exists, whether NetSuite has since delivered the same thing natively, and whether it remains the right method, keeps the count roughly stable.
That third question catches a specific and common situation, where a script solves a problem Oracle later solved in a release. The script still works, so nobody revisits it, and the business pays maintenance on a custom solution to a solved problem indefinitely.
An arrangement that only ever adds is one whose value declines over time, because the account becomes progressively harder to change.
The differences show up in a few specific places.
Proactive work is the clearest signal. An arrangement that only responds to tickets is a help desk. One that tells you a script has been failing, that a role has more access than it should, or that a release contains something worth enabling is doing the job properly.
Continuity of people matters. The same team month after month accumulates knowledge of your account. A rotating pool means re-explaining your business repeatedly, and the arrangement never becomes more efficient.
Documentation as an output matters, because an arrangement that leaves you no better documented has simply relocated your key person risk outside the business.
Clear scope and response tiers matter. A blocked invoice run and a request for a new saved search are not the same urgency and should not share a target.
And willingness to say no matters. A provider who builds whatever is asked is easy to work with and leaves you with an account nobody can safely change.
Beyond the obvious commercial ones, a few are diagnostic.
What proactive work is included, and what did you find for a client last month that they had not asked about? A provider who cannot answer the second half does reactive work only.
Who specifically will hold our account, and who covers their leave?
What happens when we exceed the included scope, and how will we know before it happens?
How do you handle the release cycle, and will we see the test results?
What documentation will we hold after a year?
And if we brought this in house, how would the handover work? Comfort with that question is a reasonable proxy for confidence in the service.
The best moment to arrange this is before go live rather than after, for a practical reason.
A provider engaged during the final phase of implementation absorbs context while the project team is still assembled and the decisions are still fresh. Engaged six months later, they spend the first month reconstructing what was decided and why.
Where the implementation partner also provides the ongoing service, that transfer is seamless, which is an argument for considering both when selecting a partner rather than treating them as separate decisions.
Where they are separate, insist on a proper handover with documentation rather than an introduction and a set of credentials.
Support arrangements drift into being judged on responsiveness alone, which misses most of what they should produce.
Better measures are whether reporting has improved, meaning fewer things assembled in spreadsheets and more available in the system.
Whether requests are being closed rather than accumulating, and how long a typical one waits.
Whether anything proactive has been raised, meaning problems found before you reported them.
Whether the account is better documented than it was a year ago.
And whether anything from the last two releases has actually been adopted, which is the clearest indicator of whether the arrangement is forward looking or purely reactive.
The return is mostly in things that do not happen. Requests that do not queue, so people stay on the system. Reporting that gets built, so the visibility that justified the investment actually arrives. Scripts that do not fail silently for a quarter. Releases that do not break anything. Customisations that do not get built because someone knew a standard feature already existed.
Set against the cost of a NetSuite licence and implementation, an ongoing arrangement is a modest addition. Set against the cost of a system people work around, it is the difference between the investment returning and not.
The honest caveat is that the return depends on the arrangement being used. A business that never raises requests, never reads the monthly summary and never acts on what the provider surfaces is paying for capacity it is not consuming.
Our managed services page sets out how we structure this, and the related pieces on support and report writing cover the two areas most businesses need first. Where the account already has problems that ongoing support alone will not resolve, implementation rescue is the more direct route.
Our piece on post implementation strategies covers the first year in detail, and the system administrator guide covers what the role requires where you intend to build the capability internally instead.
If you have recently gone live and have not settled what happens next, get in touch.
