Proactive NetSuite Support Is a Ratio, Not a Promise

Open five NetSuite managed services pages and you'll read the same word on all five. Proactive. Proactive partnership, proactive support, a proactive approach to your NetSuite environment.

Now try to find one that says what it means.

I've spent a long time in and around managed services, and I've come to think proactive is the most abused word in the category. Not because providers are lying - most of them genuinely intend it - but because nobody attaches a measurement to it, and an unmeasured intention loses to economics every single time.

So here's ours.

We target 70% of engagement hours on improving a customer's NetSuite account, and 30% on general support.

You can hold us to that. That's the point of publishing it.

Why reactive wins by default

Think about what actually happens inside a support relationship.

A ticket arrives. Someone's invoice approval is stuck, the month-end close is tomorrow, and this is on fire. That ticket gets worked. It should get worked. Then another one arrives, and another, and the hours in the month run out somewhere around the twentieth.

Nothing went wrong in that story. Everyone did their job. And at the end of twelve months of it, the customer's NetSuite account is in precisely the condition it was in a year ago, minus a few resolved fires. The undocumented customization is still undocumented. The module they bought and half-configured is still half-configured. The workflow everyone works around is still there, still being worked around.

This is the default state of ERP support, and it isn't a failure of effort. It's a failure of structure. Urgent work always displaces important work unless something deliberately protects the important work. In most support models, nothing does.

The word "proactive" on a website doesn't protect anything. A number you report on every week does - because the moment the ratio inverts, everyone can see it.

What has to be true to actually hit 70/30

A ratio by itself is just a slogan with a decimal point. Four things had to change structurally before we could hold it.

You have to know the account before you can improve it.

You cannot spend 70% of your hours on improvement work if you don't know what needs improving. So every Operis engagement opens with a Business Discovery: a business direction conversation led by the customer's Client Success Architect, a finance setup audit run by a finance specialist, and a technical audit inventorying enabled features, modules, users, roles, scripts, workflows, and customizations.

For most customers that technical audit is the first documented picture of their own NetSuite account they've ever had. That's not a knock on them - nobody gets handed one at go-live. But it means the first thirty days of the relationship get spent on the right work instead of discovering what the work is. It also means when we recommend something, we're recommending it against evidence rather than instinct.

Somebody specific has to own the backlog.

Improvement work needs an owner, or it becomes everyone's someday. Every Operis engagement assigns a named Client Success Architect who triages incoming cases, maintains the prioritized backlog alongside the customer's team, and runs the business reviews.

The CSA is the person who says "we can absolutely do that this month, and if we do, here's the thing you told me in January that we're pushing again." That's an uncomfortable sentence. It's also the single most valuable sentence in the relationship, and it requires a named human who has been there long enough to remember January.

Big work has to leave the support bucket.

Every tier carries a project threshold - twenty hours at Essentials, thirty at Optimize, forty at Growth. Above that, work gets scoped and quoted as a project instead of consumed from the monthly hours.

This looks like a limitation. It's the opposite. A four-month "support request" that quietly eats every available hour is how a proactive engagement turns reactive without anyone deciding to let it. Drawing the line keeps support hours available for support, and gives the bigger work the scoping and timeline it actually needed.

Everyone has to be able to see the number.

We send an activity report every Monday and again at month-end: baseline hours, consumed hours, extended hours, every case worked with its own line, and the open backlog.

The reason it goes out weekly rather than monthly isn't diligence theater. It's that a ratio you check twelve times a year is a postmortem, and a ratio you check fifty-two times a year is a steering input. If we're drifting, we find out with three weeks left to fix it.

What we've learned running it

We've been running this model for a while now - first with a handful of customers, then with a lot more. We're opening it up to the wider NetSuite ecosystem because the model held up under real conditions rather than because we hoped it would.

Three things surprised me.

1. The ratio is hardest to hold in month one and month twelve. Early on, because a new relationship surfaces a backlog of deferred problems that all feel urgent. Late on, because success breeds trust and trust breeds requests. Both are good problems. Both need watching.
2. Customers under-buy more often than they over-buy. We built a right-sizing conversation into the sales process expecting to talk people down from the flagship tier. In practice we spend at least as much time telling customers that ten hours a month isn't going to cover what they just described. Nobody expects the vendor to say that, which is exactly why it lands.
3. The technical audit changes the conversation more than anything else we do. Handing a finance leader a documented inventory of what's actually running in their account - including the dormant script nobody remembers deploying - reframes the entire relationship within three weeks. It stops being a support vendor conversation and becomes a "what should we do about this" conversation.

What a ratio doesn't fix

It doesn't make hard months easy. It doesn't prevent an integration from breaking during a release. And it's a target, not a guarantee - some months the business needs firefighting and the firefighting is the right call.

What it does is make the drift visible. When a relationship is going wrong, it almost never announces itself. It erodes, quietly, one urgent thing at a time, until someone looks up a year later and asks what happened to all that strategic work. A number reported every week makes that conversation happen in week six instead of month fourteen.

That's the whole argument. Not that we care more than anyone else - everyone says that too. Just that we picked a number, published it, and report against it every Monday.

If you're running NetSuite and can't remember the last time anyone proposed an improvement you hadn't asked for first, that's the thing worth fixing, whoever you fix it with.

Read how Operis works →

Todd Parrish is Director of Managed Services at Business Solution Partners, an Oracle NetSuite Solution Provider and Alliance Partner. He leads Operis, BSP's NetSuite managed services and support program.