# How to Run an Internal ERP Help Desk: Tiers, SLAs and Knowledge > Source: https://netray.co/erp-help/itm-run-internal-erp-help-desk-tier-model > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System it-leadership ## Erp Any ERP ## Module Support / ERP Help Desk ## Query how to set up an internal ERP help desk ## Alternate Queries - ERP support team structure tier 1 tier 2 - ERP service desk best practices - how to reduce ERP support tickets - ERP super user network setup ## 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. ## Steps ### Setting up the ERP help desk **Items:** - Create 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. - Define 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. - Name 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. - Staff tier 2 with ERP analysts who can check configuration, master data, security roles, workflows and standard reports, and who own the knowledge base. - Set 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. - Publish a short intake guide telling users what to include in a ticket and how to tell emergencies from normal requests. - Review 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. - Report to management quarterly with trends and the business cost of the top five recurring problems. ## Sections ### The three tiers and what belongs in each **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### How many support staff does an ERP need? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms ERP help desk, ERP support tiers, ERP service desk setup, ERP super user network, ERP ticket categories, ERP support SLA, ERP knowledge base, reduce ERP support tickets, internal ERP support team, ERP month-end support --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json