How to Run an Internal ERP Help Desk: Tiers, SLAs and Knowledge
how to set up an internal ERP help desk
Also searched as
- ERP support team structure tier 1 tier 2
- ERP service desk best practices
- how to reduce ERP support tickets
- ERP super user network setup
Short answer
An effective ERP help desk uses three tiers: business super users for how-do-I questions, an ERP support analyst tier for configuration, data and access issues, and technical or vendor escalation for defects and infrastructure. Categorise tickets by process and impact, set SLAs by business impact, and mine ticket data monthly to fix root causes and training gaps.
Applies to: Any ERP supported by an internal IT team, with or without a ticketing tool such as Jira Service Management, ServiceNow, Freshservice or a shared mailbox.
Setting up the ERP help desk
- 1Create a dedicated ERP queue or category in your ticket tool, separate from general IT, with required fields: process area, screen or transaction, user, impact, and a screenshot or error text.
- 2Define impact levels with examples: stops shipping or production, blocks a team, affects one user, or a question. Attach a target response and resolution time to each.
- 3Name super users in each department (finance, purchasing, planning, stores, production, sales) as tier 1, with protected time and a direct channel to the support analysts.
- 4Staff tier 2 with ERP analysts who can check configuration, master data, security roles, workflows and standard reports, and who own the knowledge base.
- 5Set tier 3 escalation: database and infrastructure teams, custom code developers, and the ERP vendor or partner, each with named contacts and a ticket hand-off format.
- 6Publish a short intake guide telling users what to include in a ticket and how to tell emergencies from normal requests.
- 7Review ticket data monthly by category, repeat issues and time to resolve, and turn the top repeat issues into training, a fix or a knowledge article.
- 8Report to management quarterly with trends and the business cost of the top five recurring problems.
The three tiers and what belongs in each
Tier 1 is closest to the work. Super users answer how-do-I questions, reset simple things within their authority, and reproduce and describe issues clearly before escalating. Most ERP tickets are training and process questions, so a good super user network removes a large share of the load from IT. Give them recognition, early access to changes and a regular forum.
Tier 2 is the ERP support analyst team. They diagnose with access to configuration, security roles, master data and logs. They handle access requests under an approval policy, data corrections through controlled scripts or screens, report fixes and workflow problems. Even a one-person tier 2 should follow the same intake and documentation, so knowledge does not live in one head.
Tier 3 handles what cannot be fixed by configuration: product defects, performance problems, integration failures and custom code. Define the hand-off: what evidence to attach, who owns the vendor case, and how the user is kept informed. Vendors respond best to cases with reproducible steps, version information and logs.
Categories and SLAs that reflect business impact
Classify by process rather than by technology. Categories such as order entry, purchasing, receiving, inventory, production reporting, costing, month-end, access, and integrations let you see where the pain is. A technology-only taxonomy like 'application error' hides which business process suffers.
Set SLAs by impact, not by who shouts loudest. A defect stopping shipments might target response in fifteen to thirty minutes and workaround within hours. A single-user question may target a business day. Publish the table, and have the plants agree to it, so expectations are shared before the first crisis.
Handle period-end differently. During month-end close and year-end, increase staffing or on-call coverage, freeze non-urgent changes and give finance a direct line. Many ERP tickets cluster in these windows and are time-critical.
Suggested ticket template Process area: Screen / transaction / report name: What I tried to do: What happened (paste exact error text): Example record (order, item, PO number): When it started / how often: Impact: stops shipping | blocks my team | affects me | question Screenshot attached: yes / no
Knowledge base and reducing ticket volume
Every resolved ticket that took more than a few minutes is a candidate knowledge article: symptom, cause, fix, and who may do it. Keep articles short and searchable by the words users type, including error messages. A self-service knowledge base reachable from the ERP menu or intranet deflects a meaningful share of repeat questions.
Fix causes rather than answering the same question forever. If twenty tickets a month are about the same screen, the screen may need a configuration change, a field made optional or better training. Treat the top repeat issues as small projects with owners and dates.
Link releases to support. When a change goes live, brief tier 1 first, circulate a one-page what-changed note, and watch ticket categories for the following week to spot side effects early.
Metrics that matter
Track volume by category, first response time, time to resolve by impact, reopen rate, tickets resolved at tier 1 versus escalated, and age of the oldest open items. Combine with a short satisfaction question on closure. These show whether the model works and where to invest.
Be careful with targets. Pressure on average resolution time encourages closing tickets prematurely. Pair speed with reopen rate and user feedback, and review samples of closed tickets for quality.
Use the data to make the case for resourcing. A table showing hours lost to the top recurring problems, and the cost of fixing them, is more persuasive than a general request for more headcount.
Common pitfalls
- !Routing ERP issues into general IT with no process-area field, so ERP-specific trends cannot be reported.
- !Super users named on paper with no time allocated, so tier 1 does not actually function.
- !SLAs defined by seniority of the requester rather than business impact.
- !Granting access or correcting data on request by email with no approval or audit trail.
- !No knowledge base discipline, so the same fix is rediscovered by different analysts.
- !Judging the team on average close time alone, which rewards closing without solving.
How an ERP-grounded AI assistant handles this
An assistant such as ERPray grounded in the ERP and its documentation can serve as a first-line answer for how-do-I questions and can help analysts check a record's status or find where an order is stuck, with the query shown. It should not approve access or change data on its own; those actions stay with the tiered process and your approval rules.
Frequently asked questions
How many support staff does an ERP need?
It depends on user count, customisation and process complexity. A common range for a mid-size manufacturer is one analyst per 100 to 200 active users, supported by a strong super user network. Heavily customised systems or frequent change need more. Measure ticket load before settling on a figure.
What is a super user and what do they do?
A super user is a business employee with deeper ERP knowledge who supports colleagues in their department, answers process questions, tests changes and feeds issues to IT. They are tier 1. The role works only when management gives them time and recognition.
Should ERP support sit in IT or the business?
Many organisations split it: IT owns infrastructure, security and technical issues, while business process owners own configuration and master data decisions. Whatever the split, define who decides what, so tickets do not bounce between teams.
How do we reduce repeat ERP tickets?
Categorise tickets by process, find the top repeat issues each month, and fix causes through training, configuration changes or better screens. Publish short knowledge articles using the wording users search for, and brief the help desk before every release.
Related
How to Run an ERP User Access Review (Quarterly Checklist)
An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.
How-toHow to Monitor ERP Performance: What to Track and Alert On
Monitor the ERP from the user's side first (response time of a few key transactions), then the layers beneath: database waits, blocking and long queries, application server health, batch and integration job duration, queues and storage. Baseline normal for each, alert on deviation, and keep history so you can answer slow-yesterday questions.
How-toERP Patching Cadence: How Often Should You Patch?
Patch the ERP stack in layers on different clocks: operating system and database monthly or quarterly, ERP vendor cumulative updates quarterly or semi-annually, and security fixes on an emergency path measured in days. Test every patch in a sandbox refreshed from production, with a scripted regression and a tested rollback.
How-toHow to Test ERP Backup and Disaster Recovery
A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items.
CIO briefingERP Integration Architecture: API vs iPaaS vs ETL
Choose by what the data does, not by tool preference. Use the ERP's own API (or its native bus) for transactional writes that must be validated by ERP business logic, ETL or change data capture for bulk analytical reads, and an iPaaS when you have many endpoints, need monitoring and retries, and lack the staff to run your own middleware. Most real estates need two of the three.
CIO briefingData Platform for ERP Data: Replica, Warehouse or Lakehouse
Start with the smallest thing that removes reporting load from the ERP: a read replica or vendor replication feed. Add a warehouse or lakehouse when you must join ERP data with other sources, keep history, or serve many consumers. Put a governed semantic layer on top, because raw ERP tables are not a usable analytics or AI interface on their own.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
AI for ERPAI Agents Over Infor ION API, BODs, and the Infor Data Lake
Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.
Stuck on Any ERP?
Talk to engineers who work inside Any ERP every week, and who build private AI that answers these questions from your own ERP data.