8 Signs Your NetSuite Support Isn't Working

Most NetSuite support problems don't announce themselves. They accumulate. A slow response here, a production change that wasn't tested in sandbox there, a developer who left the firm and took all the account context with them. By the time the relationship clearly isn't working, months of friction have already cost the business real time and money.

Quick answer

A NetSuite support relationship has a structural problem when any of these eight conditions are present: customizations break on every release and the support team does not catch the failures before the client does; the developer who built the original customizations is no longer reachable and nobody else understands the code; changes go to Production without Sandbox testing; routine questions take more than two business days to receive a substantive response; new work quotes are consistently higher than expected because the account is not fully understood; hours are billed and output is low with work the client cannot evaluate; the support partner is a generalist firm where nobody has deep NetSuite expertise; or the client has stopped requesting improvements because trust in the engagement has broken down. Any one of these signs is a problem worth addressing. Multiple signs together indicate the engagement is not structured to serve the client.

If you're reading this, you're probably already suspicious. Here are the signs that confirm it.

SUPPORT ENGAGEMENT DIAGNOSTIC 8 WARNINGS FOUND

⚠ Scripts break after every release. Your team tells you first, not your partner. CRITICAL

⚠ The developer who built your customization is no longer reachable. CRITICAL

⚠ Changes go straight to production without sandbox testing. CRITICAL

⚠ Routine questions take 3 to 5 business days to get a response. HIGH

⚠ Every small request triggers a new SOW and a kickoff call. HIGH

⚠ Partner re-learns your account and business on every support call. HIGH

⚠ No documentation of what scripts and workflows are running in your account. HIGH

⚠ You were locked into a long-term contract before any real discovery was done. MEDIUM

Recognized 3 or more? The structure of the engagement is the problem, not the individual incidents.

What you're experiencing	What it should look like
Scripts break on release weekends. Your team tells you first.	Release notes reviewed, sandbox tested. You're warned before it hits production.
The developer who built your customization is no longer reachable.	The same developer who built it owns it and fixes it.
Changes go straight to production without sandbox testing.	Every change, regardless of size, is tested in sandbox first. No exceptions.
Routine questions take 3 to 5 business days to get a response.	Same-day response on most requests. No queue between you and the developer.
Every small request requires a new SOW and a kickoff call.	Routine requests handled without formal paperwork. SOWs for large projects only.
You re-explain your account and your business on every support call.	Your account is known. Context doesn't need to be rebuilt every time.

1. Your scripts break after every NetSuite release and your partner isn't the one who tells you

NetSuite releases new versions twice a year. A partner actively maintaining your account should be reviewing the release notes for anything that could affect your customizations, testing in sandbox before the release hits production, and telling you what to expect, not waiting for your users to call in with errors.

If you consistently find out about release-related breakage from your own team rather than your support provider, the release cycle isn't being managed. It's just something that happens to your account.

2. You can't reach the developer who built your customization

There's a difference between a support account manager and the developer who actually wrote your scripts and workflows. Account managers can open tickets and relay messages. They can't diagnose why a Map/Reduce script is hitting governance limits or why a workflow is firing twice.

If the person who built your customization is no longer at the firm, or if you've never spoken directly to a developer in the engagement, that's a structural problem. When something breaks in production, you need someone who understands the logic of what was built, not someone who will ask you to describe the problem while they open the code for the first time.

3. Changes go straight to production without sandbox testing

This is one of the clearest signals of a low-quality engagement, and one of the most dangerous.

Every change to a NetSuite script, workflow, or advanced PDF template should be built and tested in a sandbox environment before touching production. A sandbox lets you verify the change behaves correctly across edge cases, confirm it doesn't break anything adjacent to what was modified, and roll back without affecting live operations if something is wrong.

A partner who pushes changes directly to production "because it's a small change" is making a risk judgment that isn't theirs to make. Eventually, a small change that wasn't tested causes a production incident. The pattern is the problem, not the specific change.

4. Response time is measured in days, not hours

Support that takes three to five business days to respond to a question that's blocking a process isn't support. It's a help desk queue that routes through people who happen to know NetSuite.

Slow response time on routine questions is a resource allocation problem: you're not a priority. Whether that's because the firm is understaffed, because your account is too small relative to their other clients, or because the engagement model isn't designed for active support, the result is the same. You're waiting.

5. Every small request triggers a statement of work

If adjusting a filter on a saved search or updating a field label on a form requires a formal scoping call, a requirements document, and a new statement of work, the engagement is structured for large implementation projects, not ongoing account support.

Active account support should handle routine requests without bureaucratic overhead. SOWs and formal scoping are appropriate for significant builds. They are not appropriate for the kind of small configuration changes that come up constantly in any live NetSuite account.

6. Your partner re-learns your account on every call

Someone actively managing your account should already know what industry you're in, what your core workflows are, what customizations are deployed, and what was worked on last. You should not be re-explaining your business on every support call.

This is more than an efficiency problem. A partner who doesn't know your account can't give you proactive advice, can't spot when a new request conflicts with something already built, and can't catch when a change is likely to have downstream effects. Account knowledge is the foundation of good support. If it's absent, you're getting reactive help from someone who is always starting from scratch.

7. You don't know what's running in your account

After an implementation, there should be clear documentation of every deployed script: what it does, what record type it runs on, what it triggers, and what would break if it were removed. Custom fields should be documented. Workflows should have clearly named states.

If your implementation partner handed off the account without this documentation, or if it was never created, your account is a black box. You may have scripts running on transactions you don't know about. Workflows may be evaluating on every save with no entry conditions. Custom fields may exist that nobody uses. None of this is visible without someone actually looking, and it won't surface until something breaks.

8. You signed a long-term contract before they understood your account

A partner who required a 12-month contract before completing any meaningful discovery has structured the engagement around retaining you, not serving you. Quality support providers don't need to lock clients in. The work and the relationship should be reason enough to continue.

If you're currently in a contract you're not satisfied with, or considering renewing one, the renewal decision is the clearest leverage point you have.

What Does a Well-Functioning NetSuite Support Engagement Look Like?

For comparison: a support relationship that's working looks like this.

Your partner knows your account without being reminded. Changes are built in sandbox and tested before production, without exception. When a NetSuite release is coming, you hear about it in advance, not after. Routine requests get handled without formal SOWs. If you have a question, you hear back the same day. And you have a clear picture of what's running in your account, because it was documented.

If that description sounds like a higher standard than what you're currently experiencing, it's worth knowing it's the baseline, not a premium. For a breakdown of what NetSuite post-go-live support should include, that page covers the service model in detail. If you have already decided to switch, the NetSuite partner replacement page covers what the transition looks like, what stays in your account, and what a new partner does in the first 90 days. If you are currently on Oracle's Advanced Customer Support (ACS), the NetSuite ACS alternative page covers what ACS does and does not include, and how a third-party engagement compares. To verify whether your current setup covers the essentials, the post-go-live checklist and the month-end close checklist identify what a well-managed NetSuite account should have in place.

What Should You Do If Your NetSuite Support Is Not Working?

If several of these signs match your current engagement, the practical next step is a conversation, not a commitment. We work with post-go-live NetSuite accounts exclusively. We do not require long-term contracts. And the first thing we do with any new account is actually read it, before suggesting anything.

Tell us what's going on in your account. We'll let you know honestly what we see and what we'd do about it.