The NetSuite Support Guide: Triage, Fixes, and Governance
Most NetSuite support content explains which plan to buy. This one explains how to run the function: how to classify an incident, diagnose it in fifteen minutes, fix the eight failures that generate the majority of tickets, and govern two releases a year without breaking month-end.
Short answer
NetSuite support is the operating discipline that keeps a live NetSuite account accurate, available, and improving. It spans four working layers: incident triage, account administration, functional and technical resolution, and release governance. Oracle covers platform defects and outages. Everything downstream of that, meaning configuration, scripts, integrations, data quality, and user capability, belongs to your internal administrator or your partner.
- Oracle Basic Support is included with every subscription but only guarantees a response on Severity 1 incidents. Severity 2, 3, and 4 handling requires Premium Support or a partner arrangement.
- Roughly eight recurring failure patterns generate the majority of NetSuite tickets. Each has a repeatable diagnostic path and a permanent fix.
- Two mandatory releases per year make change control non-optional. Your Release Preview account takes five to seven calendar days to build and is purged after fourteen days without login.
- Measure support on mean time to resolution by severity, recurring-issue ratio, and change failure rate. Hours consumed is an input, not an outcome.
What this guide covers
- The four layers of NetSuite support
- Step 1: Inventory your support surface
- Step 2: Build a severity model
- Step 3: The first fifteen minutes
- Step 4: Eight root-cause playbooks
- Step 5: Release governance
- Step 6: Choose a support model
- Step 7: Measure what matters
- Step 8: Write the runbook
- The 90-day rollout plan
- Seven expensive mistakes
- Frequently asked questions
The four layers of NetSuite support
The single most common cause of a stalled NetSuite ticket is not technical. It is that nobody agreed in advance who owns that category of work. A user reports that a report is wrong, the internal administrator assumes Oracle will investigate, Oracle correctly closes the case because the report is a custom saved search, and eleven days evaporate.
Separate the work into four layers and assign each one a named owner before you need them.
| Layer | What it covers | Typical owner | Signal that this layer is failing |
|---|---|---|---|
| 1. Platform | Availability, product defects, data centre performance, release delivery, standard feature behaviour | Oracle, through a support case | Repeated outages or a confirmed defect with no fix scheduled |
| 2. Administration | Roles and permissions, forms, fields, lists, saved searches, dashboards, user provisioning, sandbox refresh | Internal administrator, or an outsourced administration service | Access requests queue for days; nobody knows which role a user actually holds |
| 3. Functional and technical | Workflows, SuiteScript, integrations, custom records, period close mechanics, reporting logic, data remediation | Consultant or partner team with account-specific knowledge | The same error returns every month and is handled as a new ticket each time |
| 4. Governance | Release testing, enhancement backlog, change control, documentation, adoption, security review | A named business owner, supported by the partner | No one can say what changed in the account last quarter or who approved it |
Use this as an intake rule, not a diagram. Put the four layers on your ticket form as a required field. Within a month you will know exactly where your support load concentrates, which is the only credible basis for deciding whether to hire an administrator, buy Premium Support, or engage a partner.
Layer 1 is the only layer Oracle owns. This matters commercially: Oracle explicitly excludes enhancement requests, meaning any request to add functionality or improve performance beyond the published specification, from support services. If your ticket is really a request to change how NetSuite behaves for your business, no support tier will resolve it. It is a backlog item, and it needs layer 3 and layer 4 capacity.
Step 1: Inventory your support surface
You cannot support what you have not counted. Before writing a single service level target, spend one working day producing an inventory of everything in the account that can break. Most teams are surprised by the result, particularly the number of scripts and saved searches inherited from an implementation that ended two years ago.
Run these in order, in production, from the Administrator role. Export each list.
For each item, capture four things: what it does in business terms, who asked for it, whether it is still used, and what breaks if it stops. That last column is your severity model in draft form.
What to look for while you count
- Scripts with no documented owner. Every implementation leaves them. An undocumented script that touches transaction records is the single highest-risk object in most accounts, because nobody will understand its side effects during a release test.
- SuiteScript 1.0 still deployed. Oracle has long positioned SuiteScript 2.x as the supported development model. Version 1.0 code remaining in production is technical debt that will surface as a release incident eventually. Log it, rank it, and schedule the rewrite.
- Integrations using token-based authentication that has not been reviewed. Check the authentication method on every integration record. Where an integration still relies on credentials tied to a departed employee, you are one deactivation away from a silent sync failure.
- Saved searches with formula criteria running on dashboards. These are the most frequent cause of slow dashboards and are trivially fixable once identified.
- Roles created for a single person. Permission sprawl grows quietly and becomes an audit finding, not a support ticket, which is why nobody catches it early.
Practical target. A mid-market account with two to four subsidiaries typically carries 15 to 40 active scripts, 3 to 8 integrations, and several hundred saved searches, of which fewer than a third are still used. Retiring dead objects before you negotiate a support agreement reduces both your risk surface and the scope you are paying someone to cover.
If you would rather not run this yourself, a structured NetSuite health check produces the same inventory with a risk rating attached to each finding.
Step 2: Build a severity model your business actually recognises
Oracle classifies every incident into one of four severity levels, and your support entitlement determines which levels you can raise and how quickly Oracle responds. Start with those definitions, because they govern the cases you file, then translate them into language your finance and operations teams will use.
| Severity | Basic Support | Premium Support |
|---|---|---|
| Severity 1, Critical Production down or a core business process unusable | 2 hours, 24 hours a day, 7 days a week, via the toll-free line | 1 hour, 24 hours a day, 7 days a week |
| Severity 2, Significant Major feature impaired, no acceptable workaround | Not covered | 2 hours, with expanded coverage |
| Severity 3, Less significant Minor loss of function, workaround available | Not covered | 8 hours |
| Severity 4, Minimal Minimal business impact, question or cosmetic issue | Not available at this level | 2 business days |
The commercial consequence that surprises people. Basic Support is included with your subscription, but it guarantees a response only on Severity 1. A broken approval routing that stops purchase orders is real business pain and is almost never a Severity 1. Under Basic Support it has no response commitment at all. That gap, not the headline response times, is why most growing NetSuite accounts end up buying Premium Support, engaging a partner, or both.
Oracle assigns the severity level, and can reclassify an incident based on its actual impact on the service. Your internal model therefore needs to do something different: predict how Oracle will see it, and route the ninety percent of tickets that never reach Oracle at all.
Translate severity into business events
Abstract definitions produce arguments. Named events produce fast decisions. Write your model as a list of things that actually happen in your business.
S1, stop everything
Nobody can log in. Orders cannot be entered or fulfilled. Invoices cannot be issued. The general ledger is out of balance. A data exposure is suspected. Target: acknowledge within 15 minutes, continuous work until service is restored, executive notified.
S2, a department is blocked
An integration has stopped syncing. Month-end close is blocked. Approval routing is broken. A pricing or tax calculation is producing wrong figures. Target: respond within 2 business hours, workaround same day, permanent fix within 5 business days.
S3, degraded but working
A report returns the wrong totals but the data is correct underneath. A dashboard times out. A user has the wrong permissions. A form field is missing. Target: respond within 1 business day, resolve within 10 business days.
S4, request or question
How do I run this? Can we add a field? Can this report include last year? These are backlog items, not incidents. Target: respond within 2 business days, then triage into the enhancement backlog with an owner and a release slot.
Two rules make this model hold up under pressure. First, the person reporting the issue does not set the severity; the triage owner does, using the list above. Second, an S4 that repeats more than three times in a quarter is automatically re-graded, because a recurring question is a training or design defect wearing a costume.
Step 3: The first fifteen minutes
Good NetSuite support is mostly good triage. The goal of the first fifteen minutes is not to fix anything. It is to answer one question: which of five things is this? A data problem, a permission problem, a customization problem, an integration problem, or a platform problem. Get that right and resolution is usually straightforward. Get it wrong and you will spend two days debugging a script that was never involved.
Work this sequence in order. Stop as soon as you have a confirmed cause.
-
Establish scope in three questions
Is it one user or everyone? One record or every record of that type? Did it work yesterday? These three answers eliminate most of the search space immediately. One user plus every record points at roles. Everyone plus one record points at data. Everyone plus everything plus "it worked yesterday" points at a change or a release.
-
Read the record's own history before anything else
Open the affected record, go to the System Information subtab, and read System Notes. It tells you which field changed, to what value, by which user or script, and exactly when. This single step resolves a large share of "the data is wrong" tickets in under two minutes, and it identifies whether a human or an automation made the change.
-
Check whether anything changed in the account
Most incidents follow a change. Look for deployments, workflow releases, and feature toggles that landed in the previous seventy-two hours.
Customization > Scripting > Script Deployments (sort by Last Modified) Customization > Workflow > Workflows (check Release Status) Setup > Company > Enable Features (compare against your documented baseline) -
Read the execution logs
If a script or workflow is in scope, the logs will usually name the failure directly. Filter by date and severity, and look for the first error rather than the loudest one. The first error is the cause; everything after it is consequence.
Customization > Scripting > Script Execution Log Customization > Workflow > Workflows > [workflow] > Execution Log / History -
Reproduce under a different role
If the report is user-specific, log in as the affected user, or replicate their exact role, and reproduce. Then compare against the Administrator role. If it works as Administrator and fails as the user, you have a permissions issue and you can stop diagnosing and start fixing.
Setup > Users/Roles > Manage Roles Setup > Users/Roles > View Login Audit Trail (confirm which role was actually used) -
Confirm whether it is genuinely Oracle's
Only after the four checks above should you conclude the platform is at fault. Search SuiteAnswers for the exact error string first; a large proportion of platform behaviour is already documented there. If it is a genuine defect or outage, file the case with the reproduction steps, the affected record internal IDs, the role used, and the timestamps. Cases filed without these details get bounced back for information, and the clock keeps running.
Write the answer down, even for trivial tickets. The triage note should record the scope answers, the cause category, and the fix. Ninety days of these notes is the dataset that tells you where to invest. Support teams that skip this step end up re-solving the same problem indefinitely, which is expensive and entirely avoidable.
Step 4: Eight root-cause playbooks
Across live NetSuite accounts, a small set of failure patterns produces most of the ticket volume. Each one below follows the same anatomy: what the user reports, how to diagnose it, how to fix it, and how to stop it recurring. The prevention line is the one that matters. A support function that only fixes will stay busy forever.
1. A saved search, report, or dashboard times out
"The dashboard spins forever." "The report used to run in seconds and now it does not finish." Often worse at month-end, and worse for users in one subsidiary.
- Open the search and run it with no results displayed. If it returns fast, the cost is in rendering, not retrieval, and the fix is fewer columns or a lower row limit.
- Inspect the criteria for formula fields. A formula in criteria forces evaluation across every candidate row rather than using an index, and this is the most common cause by a wide margin.
- Check for criteria on joined records, especially transaction lines joined to items joined to a custom record. Each join multiplies the work.
- Check whether the search is set as a dashboard portlet refreshing for hundreds of users simultaneously.
- Check the date range. Searches built during implementation with no date filter grow linearly forever.
- Replace formula criteria with standard field criteria wherever the logic allows. Where a formula is unavoidable, add a cheap standard filter first, for example a date range or a status, so the formula evaluates against a much smaller set.
- Add a mandatory date filter to every operational search, defaulting to a relative range such as the current period rather than an absolute date.
- Move summary-heavy analysis off the dashboard and into a scheduled email delivery of the saved search.
- Remove columns nobody reads. A twelve-column search run by ninety people is a real load.
Adopt a rule that no saved search goes on a shared dashboard without a date filter and a documented owner. Review the top twenty most-run searches once a quarter. This is a two-hour job that repays itself immediately in restored performance.
2. A scheduled or Map/Reduce script fails partway through
"Half the invoices got updated and half did not." The execution log shows SSS_USAGE_LIMIT_EXCEEDED, SSS_TIME_LIMIT_EXCEEDED, or SSS_INSTRUCTION_COUNT_EXCEEDED.
NetSuite meters server-side work in usage units. Every API call deducts units from a fixed budget, and when the budget is exhausted the script is terminated mid-execution. The budget depends on script type: a user event script gets 1,000 units, and each scheduled script execution or Map/Reduce function invocation works within its own allowance, with a scheduled script permitted up to 10,000 units per run.
The tell is a script that passed testing against fifty records and fails against five thousand. Check the execution log for the record count processed before termination, then look for these three patterns in the code:
- A
record.load()inside a result loop, which is far more expensive than reading the field you need. - A saved search returning thousands of rows with no pagination.
- Bulk work running in a user event or client script instead of a scheduled or Map/Reduce script.
- Replace
record.load()plussave()withrecord.submitFields()where you are only changing a handful of fields. The unit saving per iteration is substantial. - Return only the columns the logic uses, and filter in the search rather than in JavaScript.
- Move bulk processing to a Map/Reduce script, which is designed to chunk work and yield between stages rather than run to a single hard ceiling.
- For scheduled scripts, monitor remaining units and reschedule before you run out, so the job resumes cleanly instead of dying mid-record.
Governance limits are fixed and cannot be raised, so design inside them. Require every new script to be load-tested in sandbox against production-scale volumes, not sample data, and require log.audit() checkpoints that record remaining units at each major stage. When a failure does happen, the log then tells you where the budget went.
3. "You do not have permissions to access this record"
A user cannot open a record, cannot see a field, or cannot find a menu item that a colleague can see. Frequently appears immediately after a promotion, a department move, or a release.
- Confirm which role the user was actually in when the error appeared, through
Setup > Users/Roles > View Login Audit Trail. Users with several roles routinely report errors from the wrong one. - Check the permission on the role, not the employee record. Most access issues are role-level.
- Distinguish the three separate controls that all produce similar symptoms: the permission itself, the permission level (view, create, edit, full), and any record-level restriction on subsidiary, class, department, or location.
- Check whether the field is hidden on the custom form assigned to that role rather than restricted by permission. A field hidden on a form looks identical to a field the user cannot access.
- Adjust the role rather than granting an additional role. Stacking roles is how permission sprawl starts.
- Where one user genuinely needs an exception, create a properly named role that describes the function, not the person, so it survives their departure.
- Re-test as the user after the change, not as Administrator. Administrator bypasses most of what you just modified.
Maintain a role matrix that maps each job function to one role, and review it every six months against your current organisation chart. Treat any request for a new role as a design decision requiring approval, not an administrative task. Accounts that skip this end up with more roles than employees, which is both a support burden and an audit exposure.
4. An integration has silently stopped syncing
"Orders from the website have not come through since Friday." Nobody noticed for three days, because the failure mode is silence, not an error message. This is the most financially damaging pattern in this list.
- Establish the last successful transaction timestamp on both sides. The gap tells you when it broke, which usually tells you what broke.
- Check authentication first. Token-based credentials tied to an employee record stop working the moment that employee is deactivated, and the resulting failure is often logged only on the external platform.
- Check
Setup > Integration > Integration Governanceand the integration record for concurrency limits being hit during peak windows. - Check whether a required field was added to the target record type. A new mandatory field will reject every inbound record that does not populate it, and the implementation team that added the field rarely considers the integration.
- Check the middleware or connector logs, not just NetSuite. If the payload never arrived, the fault is upstream.
- Re-issue credentials against a dedicated integration user that is never assigned to a person, and exclude that user from offboarding processes.
- Where an integration still relies on older authentication, migrate it to OAuth 2.0 and treat the migration as a scheduled project rather than an emergency.
- Backfill the missed records deliberately, with a reconciliation count agreed with finance before and after, rather than replaying blind.
- Make the new mandatory field conditionally mandatory, or default it, so integrations are not rejected.
Every integration needs a heartbeat: a saved search that alerts when the count of records created by the integration user falls below an expected threshold for the period. Silence is the enemy, and a ten-minute alert build removes the entire failure class. Add every integration to your release test plan permanently. Further detail sits in our NetSuite integration services overview.
5. Month-end close is blocked
The period will not lock, a subsidiary will not close, or a balance sheet does not tie. Reported at 6pm on the third working day, with a hard reporting deadline the following morning.
- Work the period close checklist in order and identify the first incomplete task rather than the one generating the error. Downstream tasks fail because upstream ones did not complete.
- Look for unapproved or pending transactions dated inside the period, including pending approval journals and unposted item receipts.
- In a multi-subsidiary account, confirm the close sequence. A parent cannot complete while a child period remains open.
- For a balance difference, check for transactions posting to an account with a currency mismatch, and check that intercompany entries are paired.
- Check whether a scheduled script that posts entries failed during the period, using the playbook above. An out-of-balance ledger is frequently a symptom of a half-completed script run.
- Clear the earliest blocking task, then re-run the checklist rather than forcing later steps.
- Post correcting entries with a clear memo convention that identifies them as close remediation, so next month's investigation is faster.
- Where a script caused the imbalance, reverse its output as a set rather than record by record.
Move close support upstream. Run a pre-close review three working days before period end that checks for pending approvals, failed scheduled jobs, and unreconciled intercompany balances. Most close emergencies are visible seventy-two hours before they become emergencies, which makes this the highest-value recurring task a support function can own.
6. An approval workflow is stuck
"I approved it but it is still pending." Purchase orders, expense reports, and journals sit in limbo, and procurement escalates because a supplier is waiting.
- Open the record's workflow history and identify the exact state it is parked in and which transition it is waiting on.
- Check the approver the workflow resolved to. Supervisor-based routing breaks whenever the supervisor field on the employee record is empty or points at someone inactive.
- Check for a threshold gap. Approval matrices written as ranges frequently leave an uncovered band, and any amount landing in that band has no valid approver.
- Check whether two automations are contending, for example a workflow and a user event script both writing to the same status field.
- Confirm the workflow is actually released rather than sitting in testing mode, especially if this began after a recent change.
- Populate the missing supervisor, or repoint routing at a role rather than an individual so vacancies do not break it.
- Close the threshold gap and define an explicit catch-all branch that routes anything unmatched to a named approver rather than nowhere.
- Release stuck records deliberately through an administrative transition, and record how many were affected.
Route approvals to roles, never to named individuals. Add supervisor to the mandatory field set on the employee record, and include an approver-vacancy check in your joiners and leavers process. Build one saved search for records pending approval longer than five days, and put it on the operations dashboard so limbo is visible without anyone reporting it.
7. Duplicate and malformed master data
Three records for the same customer, inconsistent item naming, reports that undercount because the data is split across near-identical records. Usually surfaces six to twelve months after go-live, when someone tries to report on a full year.
- Quantify before acting. Build a saved search grouped on the field you suspect, filtered to counts greater than one, and get the true number. Perception is usually worse or better than reality.
- Identify the entry path. Duplicates created through an integration need a different fix from duplicates created by users, and mixing the two produces a fix that only half works.
- Check whether duplicate detection is configured and whether it is actually matching on the fields that matter for your business.
- Determine which records carry transactions. Those cannot simply be deleted and must be merged or inactivated.
- Merge records that carry transaction history rather than deleting them, and do it in a sandbox first to confirm the transaction reassignment behaves as expected.
- Inactivate rather than delete where merge is not available, so historical reporting remains intact.
- Clean in prioritised batches, starting with the records that appear in financial reporting, instead of attempting the whole file at once.
Fix the entry path in the same week you clean the data, or you will be doing this again next year. That means duplicate detection tuned to your real match fields, mandatory naming conventions enforced at the form level, and deduplication logic in the integration rather than downstream of it. Data cleanup without an entry-path fix is maintenance, not repair.
8. Emails and notifications are not arriving
Customers say they never received the invoice. Approvers say they were never notified. Nothing in NetSuite looks wrong, because from the system's perspective the message was sent.
- Confirm the message was generated at all. Check the sent email log on the record or the employee, and the workflow execution log if a workflow triggered it.
- If it was generated, the problem is delivery, not NetSuite. Check whether your sending domain is properly authenticated for the service, because unauthenticated mail is increasingly rejected outright by recipient providers rather than being delivered to spam.
- Check the recipient address on the record itself. A trailing space or a stale address is a surprisingly common single-recipient cause.
- For approval notifications specifically, confirm the employee record holds a valid email and that notification preferences have not been switched off at user level.
- Check whether a bounce has caused the address to be suppressed after repeated failures.
- Complete domain authentication for your sending domain, then re-test to an external address on a different provider, not an internal one. Internal mail often delivers when external mail does not, which masks the problem.
- Correct the recipient data at source and add validation to the form so it cannot recur.
- Where a specific provider is rejecting messages, work from the actual bounce reason rather than guessing.
Treat email deliverability as configuration you own, not as a feature that works automatically. Verify domain authentication once a year and immediately after any change to your mail provider. Add an external-address test to your release checklist, because email templates and sending behaviour are both affected by releases.
For a deeper walkthrough of individual error conditions and their resolutions, see our companion article on the most common NetSuite support issues and how to fix them.
Step 5: Release governance, the part most teams skip
NetSuite updates every account twice a year. You do not choose whether to take the release, only how prepared you are when it lands. Accounts that treat releases as an event they attend rather than a process they run generate a predictable spike in incidents twice annually, and those incidents arrive during the weeks when finance is least able to absorb them.
The 2026.2 release illustrates the cadence. Oracle announced it on 15 July 2026 and began upgrading accounts in phases from mid-August, with the rollout continuing through the end of the third quarter. Your specific date is not announced publicly; it appears in the New Release portlet on your dashboard, typically showing the exact date and time roughly three weeks ahead.
The mechanics you need to know
- Release Preview is a real copy of your account. It is built from a backup of your production data and includes your configurations, customizations, and user passwords, so you are testing your actual environment rather than a demo.
- It takes five to seven calendar days to build after you submit the request. Request it the week the release is announced, not the week before your upgrade.
- It is purged after fourteen consecutive days without login, and access ends when your production account is upgraded. Schedule your testers, or you will lose the environment before you use it.
- Sandbox receives the release roughly four weeks before production, which gives you a second testing window if your sandbox mirrors production closely.
- Upgrade dates can often be rescheduled. Accounts hosted on Oracle Cloud Infrastructure can request a different window through Customer-Scheduled Maintenance, using the reschedule link that appears in the New Release portlet as the date approaches. Move the date off your close week if it lands there.
A release test plan that fits in one week
Reading the full release documentation end to end is a poor use of time. Test what you actually run, in this priority order.
| Test area | What to verify | Who signs off |
|---|---|---|
| Customizations | Every active script and workflow executes without new errors; check the execution log for warnings that were not there before | Technical owner or partner |
| Integrations | Each connection authenticates and completes a round trip with a test record; confirm with your connector vendor whether they have certified the release | Integration owner |
| Core transactions | Order to cash and procure to pay, end to end, including an approval and a correction | Operations lead |
| Period close | Run a close simulation on the preview data, including your key financial reports | Controller |
| Saved searches and reports | The twenty most-used searches return the same row counts and totals as production | Report owners |
| Roles and forms | Spot-check three representative roles for changed visibility or new fields on custom forms | Administrator |
| New features | Review only the features relevant to modules you use, and flag anything requiring additional licensing before planning a rollout | Business owner |
Document every issue with a named owner and a decision. The output of release testing is not a list of observations. It is a list of items, each either fixed before the upgrade, accepted with a workaround, or scheduled afterwards. Anything without one of those three outcomes will become a support ticket on upgrade day.
The 2026.2 release also began the rollout of NetSuite Next, which embeds AI more deeply across records and analytics and introduces a redesigned experience. You can explore it in a preview account before switching, and adopt it one team at a time rather than account-wide. Treat that as a change programme with its own testing and training, not as a release item. Our breakdown of what shipped in NetSuite 2026.2 covers the feature detail by role.
Step 6: Choose a support model that matches your change rate
By this point you know your surface area, your severity distribution, and where your tickets concentrate. That is enough to choose a model on evidence rather than on a sales conversation. The variable that matters most is not company size. It is change rate: how often your business asks NetSuite to do something new.
| Model | Fits when | Typical commercial shape | Where it fails |
|---|---|---|---|
| Oracle Basic Support | Simple configuration, capable internal administrator, low change rate | Included with the subscription | No response commitment below Severity 1 |
| Oracle Premium Support | You need committed response times across all four severity levels | Additional subscription fee | Covers platform incidents, not your customizations or process design |
| Advanced Customer Support | You want proactive Oracle advisory and account reviews | Priced as a percentage of annual licence value | Advisory that stops short of building the fix; you still need a developer |
| Partner on demand | Low, unpredictable volume; you want to pay only for what you use | Hourly, commonly in the region of 150 to 250 US dollars per hour | No retained account knowledge and no proactive work |
| Partner managed support | Steady change rate, several integrations, multi-entity, or a demanding close | Fixed monthly retainer with a defined capacity | Wasteful if your genuine volume is one or two issues a quarter |
The right comparison is cost per resolved issue, not headline rate. A consultant at the top of the hourly range who resolves an issue in one hour is cheaper than a retainer if your account generates one issue a year. An account generating fifteen issues a month inverts that arithmetic completely, and at that volume the retained account knowledge is worth more than the rate.
Keep in house when
- Your administrator has genuine capacity, not a job title bolted onto a finance role
- Change requests are rare and rarely technical
- You have documented your configuration well enough that one departure does not erase your knowledge
Engage a partner when
- Tickets require SuiteScript, integration work, or process redesign
- Release testing is not happening because nobody owns it
- The same issues recur because nobody has time for root cause
- You need coverage across time zones or through close periods
Where to go next on this question. This guide is about running support. For the commercial detail, including EPIQ's coverage windows, response commitments, and engagement models, see NetSuite support services. If you are weighing a fully managed arrangement, compare it against NetSuite managed services. If you are specifically evaluating Oracle's Advanced Customer Support, our ACS alternative comparison sets out the differences tier by tier. For day-to-day account upkeep alone, NetSuite administration services is usually the closer fit.
Step 7: Measure what matters, not what is easy to count
Hours consumed is the metric most support relationships report on, and it is close to useless. It measures effort, not outcome, and it rewards a provider for taking longer. Track these seven instead. Six of them can be built from your ticket data in an afternoon.
| Metric | How to calculate it | Working target | What a miss tells you |
|---|---|---|---|
| Mean time to resolution by severity | Average elapsed time from report to confirmed fix, split by S1 to S4 | S1 under 4 hours, S2 under 2 days, S3 under 10 days | S1 fine but S3 drifting means capacity is going to firefighting |
| Recurring-issue ratio | Tickets matching a cause already seen in the last 90 days, divided by total tickets | Under 15 percent | You are fixing symptoms. Root cause work is not being funded |
| First-contact resolution | Tickets closed without reassignment or escalation | Above 60 percent | Triage is weak, or the first responder lacks account knowledge |
| Backlog age | Median age of open enhancement items | Under 60 days | Improvement work is being crowded out by incidents |
| Change failure rate | Changes causing an incident within 7 days, divided by total changes | Under 10 percent | Testing and release control are inadequate |
| Release readiness | Percentage of your release test plan completed before the upgrade date | 100 percent, every cycle | You will absorb the release as unplanned support load |
| Adoption depth | Active users by role against licensed users, plus transactions entered directly versus imported | Rising quarter on quarter | People are working around NetSuite in spreadsheets |
Review these quarterly with a business owner present, not monthly with IT alone. The recurring-issue ratio and the backlog age are the two that change behaviour, because they expose the difference between a support function that is busy and one that is making progress. A provider reporting only ticket counts and hours consumed is reporting on their own activity, not on your outcome.
Step 8: Write the runbook
Every account has a knowledge problem eventually. Someone leaves, a partner changes account manager, or a customization from 2023 has to be modified by someone who has never seen it. The runbook is the artefact that makes support survivable across those transitions, and it is short enough to write in a week.
What belongs in it
- Escalation map. Who to contact at each severity, in what order, with phone numbers. Include the out-of-hours path and the Oracle case-filing procedure with your account identifiers.
- Authorized contacts. The named individuals permitted to file cases with Oracle, and the process for substituting one. Discovering during an outage that your only authorized contact left in March is a preventable emergency.
- Configuration baseline. Enabled features, subsidiaries, active integrations, custom roles, and the current script and workflow inventory from step 1. Refresh it every release.
- Known behaviours. Every quirk somebody discovered the hard way. Why that report excludes intercompany. Why the sync runs at 2am. Why nobody touches that workflow. This section saves the most time and is the one always omitted.
- Close checklist. The ordered sequence, with owners and a pre-close review three days out.
- Release procedure. Who requests Release Preview, who tests what, who signs off, how issues are logged.
- Change log. Every configuration change with date, requester, approver, and what it touched. This is what lets you answer "what changed" in step 3 of triage in thirty seconds instead of three hours.
Keep it in one place your whole team can reach, not in a consultant's document folder. Assign an owner and a quarterly review date. A runbook nobody maintains is worse than none, because people trust it.
The 90-day rollout plan
If you are building this from nothing, work in this order. The sequence is deliberate: each phase produces the evidence the next phase needs.
| Phase | Do this | You should end with |
|---|---|---|
| Days 1 to 15 Establish | Complete the surface-area inventory. Define the four ownership layers and name an owner for each. Publish the severity model. Stand up a single intake channel and stop accepting tickets by direct message. | An inventory, an owner map, and one place tickets arrive |
| Days 16 to 45 Stabilise | Work the backlog using the triage sequence. Record cause category on every ticket. Apply the playbook fixes for anything matching the eight patterns. Build integration heartbeat alerts. | A 30-day dataset showing where your load actually concentrates |
| Days 46 to 70 Systematise | Write the runbook. Build the metric set. Fix the top three recurring causes at root rather than at symptom. Run the pre-close review for the first time. | A documented account and a measurable baseline |
| Days 71 to 90 Govern | Prioritise the enhancement backlog with the business. Build the release test plan. Choose your support model using the evidence from days 16 to 45. Set the quarterly review cadence. | A funded roadmap and a support model chosen on data |
Accounts that have already drifted a long way past go-live sometimes need to compress this. If period close is regularly at risk, or a stalled project left the account in a state nobody fully understands, a NetSuite rescue engagement addresses the underlying condition first. Running a support process on an unstable account produces tickets faster than anyone can close them.
Seven expensive mistakes
- Buying hours instead of outcomes. A block of hours with no defined response commitment, no named team, and no root-cause expectation is a purchase order, not a support arrangement. Specify what gets resolved, how fast, and by whom.
- Letting the reporter set severity. Everything becomes urgent, and genuine S1 incidents lose priority in the noise. Triage owns severity.
- Treating releases as an IT event. Twice a year, your close process and your integrations are both at risk. If finance and operations are not in the test plan, the release will find the gaps for you.
- No root-cause budget. If every available hour goes to incidents, the recurring-issue ratio never falls and support cost rises permanently. Ring-fence capacity for prevention.
- Accepting a provider who will not name the team. Company reputation is not delivery capacity. Ask who performs the work, how much of their time you get, and what happens when that person is unavailable.
- Documentation as an end-of-project task. It never happens. Require the change log and runbook update as part of closing each ticket, not as a phase.
- No exit path. Agree upfront what you receive if the relationship ends: documentation, credentials, source code for custom scripts, and a transition period. A provider confident in their work will agree to this readily.
Frequently asked questions
What is NetSuite support?
NetSuite support is the ongoing work of keeping a live NetSuite account accurate, available, and improving. It covers four layers: platform incidents handled by Oracle, day-to-day administration such as roles and saved searches, functional and technical resolution covering workflows, scripts and integrations, and governance covering release testing, change control, and the enhancement backlog. Oracle owns only the first layer. The rest belongs to your internal administrator or your partner.
What is included in NetSuite Basic Support?
Basic Support is included with every NetSuite subscription. It provides 24 hours a day, 7 days a week coverage for Severity 1 critical issues through a toll-free number, online case submission, and access to the SuiteAnswers knowledge centre and the support community. It does not carry a response commitment for Severity 2, 3, or 4 incidents, and Severity 4 is available only to Premium Support customers. It also excludes enhancement requests, meaning anything that adds functionality beyond the published specification.
What are NetSuite's severity levels and response times?
Oracle uses four severity levels. Under Premium Support the response goals are approximately one hour for Severity 1 critical, two hours for Severity 2 significant, eight hours for Severity 3 less significant, and two business days for Severity 4 minimal. Basic Support targets around two hours for Severity 1 and carries no commitment at the other levels. Oracle assigns the severity and may reclassify an incident based on its actual impact on the service.
How do I troubleshoot a NetSuite issue before raising a case?
Work a fixed sequence. Establish scope by asking whether it affects one user or everyone, one record or all records, and whether it worked yesterday. Read System Notes on the affected record to see what changed and who changed it. Check script deployments, workflow releases, and feature toggles from the last 72 hours. Read the script and workflow execution logs, looking for the first error rather than the loudest. Reproduce under the affected user's role and compare against Administrator. Only after those five checks should you conclude the platform is at fault, and search SuiteAnswers for the exact error string before filing.
Why does my NetSuite script fail with SSS_USAGE_LIMIT_EXCEEDED?
NetSuite meters server-side work in usage units, and terminates a script when it exhausts its allowance. Limits vary by script type, with a user event script allowed 1,000 units and a scheduled script up to 10,000 units per run. The usual causes are loading full records inside a loop instead of using submitFields, running unpaginated searches that return thousands of rows, or performing bulk work in a user event script. The fixes are to reduce per-iteration cost, move bulk processing to a Map/Reduce script, and reschedule before the budget runs out. Governance limits are fixed and cannot be increased, so scripts must be designed to work within them.
How often does NetSuite release updates, and can I delay one?
NetSuite delivers two mandatory releases a year to every account. You cannot decline a release, but you can often move your date. Your scheduled upgrade appears in the New Release portlet on your dashboard, typically around three weeks ahead, and accounts hosted on Oracle Cloud Infrastructure can request a different window through Customer-Scheduled Maintenance using the reschedule link in that portlet. Move the date if it falls on your close week.
How do I get a NetSuite Release Preview account?
An Administrator requests it at Setup, Company, Release Preview. The account is built from a backup copy of your production data and takes approximately five to seven calendar days to create after the request. It is purged after fourteen consecutive days with no login activity, and access ends on the day your production account is upgraded. Request it as soon as the release is announced and schedule your testers in advance so the window is not wasted.
How much does NetSuite support cost?
It depends on the model. Basic Support is included with the subscription. Premium Support is an additional subscription fee. Advanced Customer Support is priced as a percentage of your annual licence value. Partner support is commonly billed hourly, frequently in the region of 150 to 250 US dollars per hour in the United States, or as a fixed monthly retainer with defined capacity. The useful comparison is cost per resolved issue rather than headline rate, because a retainer becomes cheaper than hourly billing at surprisingly modest ticket volumes.
Should I use Oracle Advanced Customer Support or a NetSuite partner?
They solve different problems. ACS provides proactive Oracle advisory, account reviews, and release readiness guidance across its service tiers. It generally advises rather than builds, so when the resolution requires rewriting SuiteScript, rebuilding a saved search, or untangling an integration, you still need delivery capacity. A partner with account-specific knowledge typically covers both advisory and execution. Many organisations run Premium Support from Oracle for platform incidents alongside a partner for everything downstream of the platform.
What should a NetSuite support agreement actually specify?
Six things, in writing. Coverage windows including out of hours. Response commitments by severity, using your severity definitions rather than generic ones. What is in scope, separating break-fix from enhancements, since the two compete for the same capacity. The named team and their availability. Documentation and change-log obligations as part of ticket closure. Exit terms covering documentation, credentials, custom script source, and a transition period. Anything left unwritten becomes an argument during your first serious incident.
Bring this into your account
EPIQ Infotech has been an Oracle NetSuite Alliance Partner since 2013, with more than 100 projects delivered across 24 countries and a 96 percent client retention rate. We run the process in this guide for mid-market teams every day: triage, root cause, release governance, and a backlog that actually moves.
Continue reading
Santosh Krishnamoorthy is a Principal ERP Consultant at EPIQ Infotech, with extensive experience in NetSuite and enterprise systems. He works with finance and operations teams to improve reporting accuracy, streamline workflows, and build ERP environments that support sustainable growth. His writing focuses on practical insights drawn from real implementation and support experience.
Free Consultation
Talk to a NetSuite Expert
Response within 1 hour
