Most ERP projects are judged on the day the system goes live. The data has been migrated, the users have logins, and the steering committee signs off. Then the real work begins. Over the next twelve months, your team will find missing fields, new reporting needs, tax rule changes, and integration problems that nobody predicted. The quality of your vendor's support during that period often decides whether the system becomes part of daily operations or quietly gets bypassed with spreadsheets.
This article sets out what a serious vendor should provide after go-live, what to write into the contract, and what to ask before you commit. It applies whether you are buying a packaged ERP System or commissioning a custom software build, and it is written with erp system in egypt conditions in mind: local tax rules, Arabic and English users, and branch offices that may be far from head office.
Why support is a separate line of work
Implementation and support are different skills. Implementation is project work with a fixed scope and a deadline. Support is operational work: answering questions quickly, fixing defects, tuning performance, and making controlled changes while the business keeps running. A vendor can be excellent at one and weak at the other.
When you evaluate vendors, ask who will answer the phone in month eight. If the answer is that the implementation team moves to the next project, you should plan for a gap and budget for it, or negotiate a support arrangement before signing.
The core support services to expect
1. A defined service level agreement
An SLA turns "we will help you" into measurable commitments. At minimum, it should define:
- Severity levels with clear examples. A month-end close that cannot run is critical. A misaligned report column is low.
- Response times for each severity, measured in business hours and, for critical issues, outside them.
- Resolution targets or, where a fix takes longer, a committed plan with dates.
- Support hours that match your working week, including the weekend days used by many Egyptian businesses and any branches that operate later.
- Channels: a ticket system, email, phone for critical issues, and who is accountable for each.
Ask for historical response data if the vendor has it. A vendor who will not share any figures at all is telling you something.
2. Defect fixing and hot-fixes
Bugs will appear. A good vendor separates fixes that are part of the original scope from new requests, and does not charge you for defects in delivered functionality. The contract should say how urgent fixes are deployed, who tests them, and how you are told what changed. Ask for a release note for every deployment, even small ones.
3. Change requests with a clear process
Your business will change: a new branch, a new product line, a new approval rule. Support is not free for these. What matters is the process. A good change request includes a short description, an impact estimate on other modules, a price or hour estimate, and a date. You approve it before work starts. Vendors who handle change informally tend to create disputes later, so insist on written change requests from the first month.
4. Monitoring, backups and recovery
Support includes keeping the system running. Confirm that the vendor provides:
- Automated daily backups, stored off the main server, with a tested restore procedure
- Uptime and error monitoring, with alerts that reach a person, not an inbox nobody reads
- Security updates for the framework, operating system and libraries
- Performance checks as the data grows, especially for reports that scan large tables
Ask the vendor to restore a backup to a test environment once a quarter and report the result. A backup that has never been restored is only a hope.
5. Training for new and existing staff
Users change jobs, and new staff arrive who never attended the original training. Your vendor should provide short refresher sessions, recorded walkthroughs of key processes, and written guides in Arabic and English where users need them. Training should also cover the reports managers actually use, not just data entry screens.
6. Regulatory and tax updates
If your ERP handles invoicing, payroll or tax, rule changes are a support obligation. Egypt's e-invoicing and tax requirements have changed over time, and a system that falls behind can stop you issuing valid documents. Confirm that the vendor monitors these changes, tells you in advance, and includes the update work in the support plan or quotes it clearly. Our article on e-invoicing in Egypt covers what your software needs to support.
What to put in the contract
Support promises that are not written down rarely survive the first crisis. Before signing, check that the contract includes:
- The SLA with severity definitions, response and resolution targets, and support hours
- The monthly or annual fee for support, and what it excludes
- The process and pricing for change requests
- Backup frequency, retention period, restore testing and where data is stored
- Who owns the source code and documentation, and whether you can take them if the relationship ends
- Exit terms: how data is returned, in what format, and how much notice is required
- Escalation: who you call when the named contact is unavailable
The last two points matter more than most buyers expect. If you cannot get your data out in a usable format, you are locked in regardless of how good the support is.
Questions to ask vendors before you sign
| Question | Strong answer | Warning sign |
|---|---|---|
| Who will support us after go-live? | A named support team with a named lead | "Our general helpdesk" |
| How fast do you respond to critical issues? | A stated target with a history you can review | "As soon as possible" |
| How do you restore backups? | Tested restores, with reports | "The hosting provider handles it" |
| What happens when tax rules change? | Advance notice and a planned update | "You will need to request it" |
| Can we take our code and data if we leave? | Yes, in documented formats | Unclear or conditional answers |
How we approach support at Narmar
We treat go-live as the start of a service period. Our ERP System work includes a defined support plan agreed during the project, and we use the same structure for ERP projects we deliver as case studies, including our Earth Movers ERP for a multi-company construction business and our Narmar POS and ERP suite for retail and restaurants. In practice, that means written SLAs, monitored systems, restore tests, and change requests that are priced before they are built.
An ERP system is judged by the first month after launch and by every month after that. Plan the support contract with the same care as the implementation plan.
Next steps
Before you approve an ERP budget, add a line for the first year of support and include the support terms in your vendor evaluation. If you are comparing options, we can review your support requirements alongside your scope and give you a clear estimate. You can contact us to discuss your project, or read our guide to measuring ERP ROI to see how support costs fit into the wider business case.
Good support is not a luxury added after the project. It is what keeps the system useful for years, and it should be visible, measurable and written into the agreement from the start.
