Notes for owners · Industry-Specific Software Guides
How an Enterprise Software Company Sets Up a Support Renewal and SLA Process
An enterprise software company sets up a support and renewal process by keeping one record per customer: contract, deployed version, severity rules and renewal date. Tickets and renewals then read from that record. GullySystem builds such a register as custom software. A company with a handful of customers can start in a sheet.
Ganesh HS, Strategy and Technology, GullySystem · · 3 min read
Start with one record per customer
Most vendors know what each customer bought. Fewer can say, in one place, which version the customer runs, where it is hosted and who the contacts are. That gap shows up the day a defect is reported.
Create a customer record that holds modules, version, environments, hosting and named contacts. Link the signed licence and any statement of work to it. Support starts every call from that page.
- Modules and user or module counts bought
- Version and patch level installed
- Hosting: customer cloud, your cloud or on premise
- Named contacts for support and for renewal
Write the contract terms into fields
A support contract carries a term, a scope, severity levels and response targets. When these live only in a PDF, nobody checks them under pressure.
Copy each term into a field on the contract record: start and end date, covered modules, severity definitions and response targets. Keep the signed PDF attached. Whether a clause binds anyone is a question for your lawyer, not for the register.
Set severity rules and escalation
A severity-one ticket on a weekend is where an SLA is tested. If the clock starts only when a person notices the email, it starts late.
Classify each ticket on arrival, start the response clock then, and name an escalation owner for each level. When a commitment is close to being missed, the owner is alerted. Record the actual response and resolution times, so reviews use facts.
- Severity levels in plain words
- Response and resolution targets per level
- Escalation owner and backup
- Clock start, pause and stop rules
Build the renewal list ahead of expiry
Annual support renewals arrive on dates that sit in different calendars. When one slips, the customer keeps raising tickets with no contract behind them.
Run a renewal list sorted by expiry date, opening well before the end of each term. Attach the ticket count and any open escalations to each line. The renewal quote then starts from what the customer used, not from last year’s figure.
Track customisations against the version
Enterprise customers often ask for changes built only for them. If these are not recorded against the customer and the version, the next upgrade breaks them without warning.
Log each custom change with the customer, the version it was built on and the module it touches. An upgrade plan can then list what to retest. Support can also tell whether a defect belongs to the standard product or to a change.
Customer support and renewal register
One row per customer, with modules, version, hosting, contract term, severity targets, renewal date and open escalations. Add a second tab listing customisations by customer and version. Review the renewal column monthly and the escalation column every week.
Open a blank worksheet to printQuestions owners ask
Does the register deploy or patch customer installations?
No. It records what each customer runs and which patch they hold. Releases and deployments stay in your build and release tooling.
Can we keep our existing helpdesk?
Yes. Many vendors keep their helpdesk and connect it, so tickets are tied to the customer’s contract and version. Connection is scoped for each tool during implementation.
Is a spreadsheet enough for this?
For a handful of customers on one version, often yes. It stops working as versions, customisations and renewal dates multiply across people.
Who should own the renewal date?
One named person per customer, usually the account owner, with support able to see the date. If everyone shares it, nobody sends the quote.