How the ERPNext support module runs after-sales service
If your company sells installed equipment or recurring service, the ERPNext support module keeps customer issues, maintenance visits and warranty claims in the same system as your sales orders, delivery notes and stock. Service records then point back to the exact Serial No that was sold and delivered, so support staff see the item history before they dispatch a technician. The module covers four connected parts: issues governed by Service Level Agreements, maintenance schedules created from a maintenance sales order, maintenance visits logged against those schedules, and warranty claims checked against serial number records. Teams usually implement it once they have sold enough installed units that spreadsheets and shared inboxes no longer show what is covered, what was visited and what is owed. It runs on the same bench as Accounting and Stock, so a replaced part, a billable visit or a credit note posts through the same ledgers rather than through a separate helpdesk export.
Before you configure anything, confirm which items carry serial numbers, which customers hold annual maintenance contracts, and who owns the warranty decision when the claim and the contract disagree. A Service Level Agreement defines the timeline in which a customer receives service and is set under Support > Service Level Agreement, so response and resolution targets should be agreed with the business owner first, not copied from a template. Maintenance schedules plan visits with a periodicity of weekly, monthly, quarterly, half yearly, yearly or random, so confirm the contract terms that drive each interval. Read the ERPNext maintenance schedule documentation and the warranty claim documentation against your own serial number practice, because a claim is only as reliable as the serial numbers recorded at delivery. Test the flow end to end with one installed unit before rollout.
What the ERPNext support module does
The ERPNext support module covers four connected areas: issues tracked against service levels, maintenance schedules planned from sales orders, maintenance visits logged against those plans, and warranty claims checked against serial numbers. Together they let a team record what customers report, when they need help, and what coverage applies to each installed item.
Issues under Support
An Issue is the record a customer's problem lives in, from the first report to closure. Support teams use it to assign ownership, track status and keep one history per problem. Before go-live, confirm which customer, item and contact fields your team needs on the issue form, and who may change its status, because those choices shape every report the module produces later.
Service level agreements
A Service Level Agreement defines the timeline in which a customer receives service. In ERPNext it is configured under Support, then linked to customers or contracts so that issues are measured against the right clock. Check how response and resolution timelines apply to each customer group, and whether your agreement covers working hours, holidays or only calendar time, since the configured timeline is what the system reports against.
Maintenance schedules from sales orders
A Maintenance Schedule is usually created from a Sales Order of type Maintenance. It plans visits on a periodicity of weekly, monthly, quarterly, half yearly, yearly or random, so the work is set before the first visit. Decide the periodicity per contract during design, because changing it later affects every visit already planned under that schedule.
Maintenance visits
Maintenance visits are the scheduled service events that the schedule produces, recording what was done at each customer site and against which items. They give finance and service leads a record of delivered work to compare with the contract. Define early who completes visit records, what detail they must capture, and how missed or rescheduled visits are reported back to the account owner.
Warranty claims against serial numbers
An ERPNext Warranty Claim records a customer's claim against a Serial No. The system fetches the serial number details and shows whether the item is under warranty or an annual maintenance contract. Serial numbers must therefore be captured at delivery, or the claim has nothing to check against, so confirm your stock process records them for every serialized item.
Which support configuration fits your service model
This table compares the support configuration choices in ERPNext's support module, from SLA definitions and maintenance sales orders to serial number discipline and companion apps. Read each row against how your organization sells and delivers service, then confirm the open items with the vendor or your implementation partner before you commit.
| Decision | Option | When it fits | What to confirm |
|---|---|---|---|
| SLA definitions | One SLA for all customers | Service commitments are uniform and few priority levels apply | Response and resolution rules are set under Support > Service Level Agreement and how they apply to each ticket |
| SLA definitions | SLAs per customer or priority | Contracts specify different timelines by customer tier or issue severity | How SLA matching works when a customer or priority has several applicable agreements |
| Service sold as | Maintenance sales orders | Customers buy planned service visits as a recurring contract | Which items and periodicity your contracts use, and how visits are billed |
| Service sold as | Warranty only | Service is limited to claims on delivered products within a fixed coverage window | How warranty periods are recorded on Serial No and whether annual maintenance contracts also apply |
| Maintenance schedule periodicity | Weekly, monthly or quarterly | Equipment needs frequent inspection or has contractual visit frequency | Whether your visit obligations match the periodicity options and how missed visits are tracked |
| Maintenance schedule periodicity | Half yearly, yearly or random | Service is light, event-driven or aligned to an annual cycle | How random visits are planned and reported against the contract |
| Serial number discipline on delivery | Serial numbers recorded on every delivery | Products are individually tracked and warranty claims must be verified against the item sold | Which items require serial tracking and how stock entries enforce it at delivery |
| Serial number discipline on delivery | Batch or no tracking | Products are consumables or interchangeable and no per-unit warranty applies | Whether warranty claims can still be linked to a customer and an item reliably |
| Module choice | Built-in support module | Issues, SLAs, visits and warranty claims fit your team's workflow and volume | Whether the interface and ticket features meet your service team's needs in your version |
| Module choice | Companion app such as Frappe Helpdesk | Your support team needs a more advanced ticketing interface than the built-in module offers | How the companion app runs alongside ERPNext on the same bench and which records stay in ERPNext |
How service records connect to sales, stock and serial numbers
Service records in ERPNext are only as complete as the transactions that feed them. A Maintenance Schedule is usually created from a Sales Order of type Maintenance, so the schedule, its planned visits and the customer's contract all depend on that order being submitted with the right customer, items and dates. If the team books a service contract as a plain sales invoice, or leaves the item list empty, the schedule has nothing to plan from and visits never appear in the calendar. Before go-live, confirm with your sales lead which order type each service contract uses and who checks the order before it is submitted.
Warranty claims depend on a different chain. A Warranty Claim is recorded against a Serial No, and ERPNext fetches that serial's details to show whether the item is under warranty or an annual maintenance contract. The Serial No record exists only if serial tracking was switched on for the item and the serial was captured on the delivery note. If a product was shipped without serial numbers, or the serials were typed inconsistently, the claim screen will show no warranty status and the support team has no reliable basis for a decision. Ask your stock lead to confirm which item groups require serial tracking and to test one delivery end to end before the module is opened to customers.
SLA timelines carry the same risk in a quieter form. A Service Level Agreement defines the time in which a customer receives service and is configured under Support, but the due dates it calculates depend on the support calendar and on the customer master data that links a ticket to an agreement. A customer record without the right SLA assignment, or a holiday calendar that does not match the region where the work happens, produces response deadlines that look correct on screen and are wrong in practice. Treat the customer master, the support calendar and the SLA rules as one reviewed configuration, and check a sample of open issues against the agreed commitments before relying on the reports.
Implementation sequence for ERPNext support
The sequence moves the support module from a clean catalog of services and contracts to a live queue where issues, SLAs, maintenance visits and warranty claims all point at the same serial numbers and customer records. Each step closes with a check the team can verify before the next one starts.
Confirm the service catalog and contract types
Before any configuration, the support lead and the service manager agree which items are serviced, which contract types apply (standard warranty, annual maintenance contract, paid visit, or none), and which teams answer which kinds of issue. This is a decision exercise, not a system task, and it should be written down in one shared document. Done when every serviceable item has a named contract type and an owner for each issue category, and the list has been signed off by the people who will answer the phone or the ticket queue.
Clean serial and customer data
Warranty claims and maintenance schedules depend on Serial No records that link each unit to a customer, an item and a warranty or maintenance period. Reconcile the existing serial lists against installed base records, merge duplicate customers, and confirm that every serviceable serial has an owner and a delivery or installation date. Ask the data owner to confirm which legacy source is authoritative when two systems disagree. Done when a sample of serials pulled from the system matches the field records for customer, item and dates.
Configure service level agreements under Support
Create the Service Level Agreements under Support in ERPNext, following the entity types and priorities the catalog defined in step one. The configuration sets the time windows in which a customer receives service, so the targets must come from the commitments in your customer contracts, not from defaults. Confirm with the business owner which working calendar and holidays apply. Done when a test issue for each priority and customer tier shows the expected response and resolution targets, and a reviewer has checked those targets against the contract wording.
Set up maintenance sales orders and schedules
Maintenance schedules are usually generated from a Sales Order of type Maintenance, so this step creates the commercial records that drive planned visits. Set the items, quantities and periodicity for each contract (weekly, monthly, quarterly, half yearly, yearly or random), and confirm which of these periodicities your service model actually uses. Have finance check that the sales order items, taxes and billing terms match the signed contract. Done when a generated schedule lists the expected visit dates for a sample contract and the dates match the agreed frequency.
Define the warranty claim process
Write the claim workflow in plain terms: who opens a Warranty Claim, what evidence the customer must supply, how the system's warranty or annual maintenance contract status is checked against the Serial No, and who decides on out-of-warranty exceptions. Agree how a claim links to any resulting maintenance visit or replacement so that costs land in the right place. Confirm with your finance and legal contacts how exceptions are approved. Done when a written process has been walked through with one or more real claim scenarios and every role in the process knows its step.
Pilot with a small set of items and customers
Run the full flow for a limited group: a few items, a small number of customers and their serials, and one maintenance contract per type. Open issues against the SLAs, generate a schedule, complete a visit, and file a warranty claim against a serial. Record every place where the system or the process disagreed with what the team expected. Keep the pilot small enough that a mistake affects only a handful of customers. Done when each test path has been completed once, every defect is logged with an owner, and the team agrees the open issues are fixable before go-live.
Go live with user training
Expand to the full catalog only after the pilot defects are closed or accepted. Train service agents, dispatchers, field engineers and finance staff on the roles they use, with exercises based on the pilot scenarios rather than generic screen tours. Set up a named contact for questions in the first weeks and a short review of SLA breaches and overdue visits. Done when every user role has completed its training exercise, access is confirmed through the role settings, and the first live issues have been handled through the new flow without manual workarounds.
Loading existing service history into ERPNext
Can the ERPNext Data Import tool load open issues, maintenance contracts and serial numbers?
Yes, the Data Import tool imports and updates records from CSV or Excel files or public Google Sheets, using downloadable templates for each DocType. Serial numbers, open support issues and maintenance records are loaded as separate DocType imports, so each one needs its own file and template. Confirm the exact fields your ERPNext version exposes in each template before you map your legacy data, because field names and mandatory columns change between releases. The Data Import documentation is the reference for template behavior.
Do child table rows import with the parent record in ERPNext?
The Data Import tool supports child table rows, so line items such as maintenance schedule visit dates or serial lines can be loaded alongside their parent document. Each child row must reference its parent using the identifier defined in the template, and parent records must exist before their children are imported. Test one parent with several child rows in a staging site first. Errors in child rows often only surface after the parent is saved, so check the import log line by line.
How many records should one import file contain?
The ERPNext documentation advises importing only a few thousand records at a time, so split large serial number and issue histories into batches. Batch size affects how long each import takes and how easy it is to find and fix errors. Run a small pilot batch, verify it, then continue in sequence. The team doing the migration should agree on the batch plan, the order of DocTypes and the rollback approach before the first production run. Confirm the batch size limit against the version you run.
Which reconciliation checks are needed before go-live for service history?
Reconciliation confirms that what ERPNext shows matches the source system and the contracts customers hold. Compare record counts per DocType and per customer, then check open issues against the legacy queue by status and owner. Verify that every active maintenance contract has its schedule and that serial numbers link to the correct item, customer and warranty dates. Sample at least one record per customer segment and read it end to end. Sign off the counts and samples with the service manager before cutover.
How do we check that warranty status is correct after migration?
Warranty claims are checked against serial numbers, so the warranty and annual maintenance contract dates on each Serial No must be correct before claims are used. Pick a sample of serial numbers covering different items, warranty periods and expired contracts, then compare what ERPNext reports with the signed contract or the original sales invoice. Errors in date formats are common when spreadsheets are exported from another system, so check date parsing in the first batch. Record the test results as evidence for the go-live decision.
Who should own the data mapping and validation work?
The business owner of service data, usually the service manager or customer support lead, should own the mapping rules and sign off on what counts as an open issue or active contract. The technical team or implementation partner writes the templates, runs the imports and keeps the error logs. Finance may need to confirm contract values if they flow into accounting. Clear ownership prevents disputes at reconciliation, when a record count is correct but its meaning is not.
What does loading service history cost, and what drives it?
Loading service history is mostly a labor cost, and the effort depends on how clean the source data is, how many DocTypes are involved and how many reconciliation rounds the business requires. The ERPNext software itself is free and open source, so costs are for the people doing the work and any hosting. Ask any provider for a quote that lists the DocTypes in scope, the number of source systems, the expected batches, the reconciliation checks and who signs off each step. Any figure should be tied to that written scope, not a generic estimate.
Can our internal team run these imports without outside help?
A capable ERPNext administrator can run the Data Import tool with the documentation, but the work is still a project with risk. The team needs a staging site, a tested mapping for each DocType, a batch plan, a reconciliation checklist and time for repeated test runs before cutover. If the team has not done a data migration before, or the source system is poorly documented, an outside partner can plan and run the migration under a written scope. DeployOpen implements ERPNext inside your own infrastructure and can take on this work under a fixed-scope agreement.
What drives the cost and effort of support configuration
This table lists the factors that most change the effort of configuring ERPNext support, with how each one shifts the work and how to keep it contained. Read it before asking for a quote, because the scope decisions you make on contract types, serial data and integrations usually matter more than the number of screens to configure. The main takeaway is that a narrow first release, with one contract type and clean serial data, is the most reliable way to control effort.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of service contract types | Each contract type needs its own maintenance schedule logic, warranty terms and SLA mapping, and each adds test cases. | Limit the first release to one contract type and add others after the first cycle of visits and claims is working. |
| Number of SLA tiers | Each Service Level Agreement tier sets response and resolution timelines and priorities, which must be checked against real tickets. | Start with one or two tiers that match contracted commitments and avoid tiers that exist only in theory. |
| State of serial number data | Warranty claims check against Serial No records, so missing, duplicate or unlinked serials cause manual cleanup before go-live. | Audit serial numbers on installed base items first and agree which records are in scope for claims. |
| Custom fields or scripts for reporting | Standard reports may not show SLA breaches or claim outcomes the way your team needs, which means custom fields, reports or scripts. Server Scripts are disabled by default from version 15 and must be enabled with server_script_enabled. | Use standard reports and list filters first, then add custom fields only for data you must report on. |
| Integration with existing helpdesk or field tools | Syncing tickets, technician schedules or asset records from another system adds mapping, error handling and ongoing monitoring. | Decide which system is the record of truth for each object and keep integrations to the fields the process needs. |
| Maintenance schedule rules | Periodicity choices (weekly, monthly, quarterly, half yearly, yearly or random) and the items each schedule covers affect how many visits must be planned and checked. | Agree the periodicity per item group up front and avoid mixing many visit patterns in the first build. |
| Technician and dispatch process | Assignment rules, visit completion steps and handover between support and field staff define how much configuration and training is needed. | Document the current dispatch steps and configure only the ones that are used today. |
| Data migration of open tickets and history | Importing historical issues, schedules and claims requires mapping, validation and reconciliation, and large files need batching, since the Data Import documentation advises a few thousand records at a time. | Migrate only open items and recent history, and archive older records outside the new process. |
How the support module connects to the rest of the platform
The support module does not run alone. Issues, maintenance visits and warranty claims pull from sales, stock, accounting and field tracking, and each link depends on how your company has configured those modules. Confirm every connection below in your own environment before you design the support process.
Selling and sales orders
Maintenance Schedules are usually created from a Sales Order of type Maintenance, so the contract that sets visit timing starts in the Selling module. Check which customer, item and service terms the sales order carries into the schedule, and who is allowed to submit maintenance orders. Confirm the periodicity options your team needs (weekly, monthly, quarterly, half yearly, yearly or random) before you build the sales process around them.
Stock, Serial No and delivery
A Warranty Claim is recorded against a Serial No, and the system fetches serial details to show warranty or annual maintenance contract status. That only works if serial numbers are captured on delivery notes and purchase receipts for the items you service. Check that serial tracking is enabled on those items and that your receiving and dispatch staff record serials consistently, because a missing serial breaks the warranty lookup.
Accounting for maintenance invoices
Billable maintenance visits, spare parts and chargeable repairs need to reach the ledger through invoices. Decide with your finance team which items are billed, which are covered by a contract, and which income accounts they post to. Confirm how the invoice references the maintenance or warranty record, so that a month-end review can trace revenue back to the service work that produced it.
Projects or Assets for field work
If field technicians work on projects or on company-owned equipment, the time and cost of a visit may belong in the Projects module or the Assets module rather than in the support record alone. Decide which module is the system of record for labor hours and asset maintenance history before go-live. Confirm whether timesheets, asset maintenance logs and support visits will overlap, and who reconciles them.
Sign-in for field technicians
Technicians who update visits and claims from the field need accounts with roles limited to support work. ERPNext supports LDAP login against Active Directory or OpenLDAP, with group-to-role mapping at each login, and Social Login Key can add OAuth or OpenID Connect providers. Confirm which identity source is authoritative for contractors and whether their roles match the least access they need.
Frappe Helpdesk as an alternative
Frappe Helpdesk is a separate open-source ticketing app from the Frappe team that can run on the same bench as ERPNext, and some teams choose it over the built-in support module for the customer-facing side. Decide early whether issues stay in the ERPNext support module or move to Frappe Helpdesk, since that choice changes which records the SLA, maintenance and warranty flows must read. Confirm the current app compatibility with your ERPNext version before you commit.
Questions buyers ask before configuring ERPNext support
What does it cost to configure the ERPNext support module?
Cost depends on the written scope, not on a list price. The main components are the discovery work to map your service catalog, SLA tiers and maintenance contracts, the configuration of Service Level Agreements, Maintenance Schedules and Warranty Claims, the data load of existing serial numbers and contracts, and testing with your service staff. Most of this is one-time work, while your own staff time for upkeep recurs. Ask for a quote that separates these items and states what is excluded. DeployOpen does not publish prices, so the quote follows from the agreed scope.
How long does a support module setup take?
Duration depends on how many item groups, SLA definitions, contracts and serial records you need to model, and how quickly your process owners can make decisions. A narrow setup covering one service desk is much shorter than one covering field visits, multiple warehouses and warranty chains across product lines. The timeline is set in the written scope before work starts. Ask for the milestones, the decisions required from your side and the dates on which each depends on them.
What do we need to provide before the work starts?
The work needs three inputs from your side:
- Serial and batch data for installed products, including item codes, customers, delivery dates and warranty terms, so Warranty Claims can check Serial No records.
- A service catalog listing the services you sell, their response commitments and the maintenance contracts that cover them.
- Named process owners for support, field service, warranty decisions and billing, who can approve SLA priorities and visit schedules.
Missing serial data is the most common blocker, because warranty checks depend on it.
Can our in-house team configure the support module?
Often yes, if you have someone who knows ERPNext's Selling and Stock modules and who can own the process design. The ERPNext documentation for Service Level Agreements, Maintenance Schedules and Warranty Claims is a usable starting point. What is harder to staff internally is the cross-check of serial history, contract terms and service priorities across teams, plus testing against real cases. Decide which parts you will own after go-live, including who updates SLA rules when contracts change.
How do Service Level Agreements, maintenance schedules and warranty claims connect?
They share customer, item and serial data but serve different steps. A Service Level Agreement sets the time frame in which a customer receives service, configured under Support. A Maintenance Schedule is usually created from a Sales Order of type Maintenance and plans visits weekly, monthly, quarterly, half yearly, yearly or randomly. A Warranty Claim records a customer's claim against a Serial No and fetches the serial details to show whether the item is under warranty or an annual maintenance contract. Engineers should test a claim on a serial whose warranty and contract dates overlap.
What breaks most often in support configuration?
The usual failures are inconsistent serial data, SLA rules that do not match contract terms, maintenance schedules created without a clear owner for visits, and claims raised against serials that were never recorded at delivery. Check each serial's warranty and maintenance dates against the contract before go-live, and run a sample of closed tickets through the new SLA rules. Also confirm who can edit SLA and schedule records, since these settings affect customer commitments.
When should we replace the ERPNext support module with Frappe Helpdesk?
Consider Frappe Helpdesk when the module's interface no longer fits how your support agents work, such as high ticket volumes, many channels or a need for a more modern agent experience. Frappe built Helpdesk because the older module's interface fell short, so the two can be compared directly. Check whether the two can run on one bench and how data moves between them before you commit. The ERPNext documentation on Service Level Agreements describes what the built-in module already covers, which is the baseline for that decision.
How DeployOpen works on this
DeployOpen configures ERPNext support in the client's own infrastructure, starting from the service workflow the business wants to run. We agree the written scope first, then build and test issues, SLAs, maintenance schedules and warranty claims against real serial number and contract data, and hand the configuration over with documentation the support team can maintain.
How we scope
- Map how service requests arrive today and which ones need an Issue, an SLA or a warranty check.
- Agree the written scope, including which items, serial-numbered products and maintenance contracts are in the first release.
- Confirm the ERPNext version and deployment, since support configuration depends on the version in use.
- Identify the customer and item data that must be cleaned before maintenance schedules are generated from sales orders.
How we build
- Configure Service Level Agreements under Support, with response and resolution timelines agreed with the business.
- Set up maintenance sales orders and schedules with periodicities that match each customer contract.
- Link warranty claims to Serial No records so warranty and maintenance contract status is checked on every claim.
- Test each workflow with sample issues and contracts before any live customer data is loaded.
How we hand over
- Deliver a written configuration record covering SLAs, schedules, roles and the warranty claim steps.
- Walk the support and service teams through issue handling, maintenance visits and claim review.
- Document any custom scripts or server-side changes, and confirm whether they are permitted in your environment.
- Agree the acceptance tests the client signs off before the support module goes into daily use.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan ERPNext version upgrades with a test copy of the support configuration before production changes.
- Review SLA performance and schedule accuracy with the client on an agreed cadence, as the retainer defines.
- Confirm with the client which changes to the support workflow are in scope for a fixed-scope project.
