Software companies are chosen on the pitch and remembered for the support. Launch day is one day. What follows it is years, and that is the part almost nobody evaluates before signing.
Here is how to rate support before you have any experience of it.
Ask what is included and what is billed
The most common source of bad feeling in a software relationship is not a bug, it is a disagreement about whether something was a bug. Get the boundary written down before you start:
- Something broken that used to work: included, obviously.
- Something that never worked as specified: included.
- A new report, a new field, a new rule: new work, and priced.
- Training a new member of staff: decide in advance which it is.
- A problem caused by a third party changing something: decide in advance.
Nobody argues about this list at the beginning. Everybody argues about it in month eight if it was never written.
Ask how a request is raised, not just who to call
A single person's mobile number is not a support system. It is a single point of failure that goes on leave. What you want is a way to raise something that leaves a record, so nothing gets lost in a chat thread, and so somebody other than your usual contact can pick it up.
Ask what happens to your request when the person who knows your system is unavailable. The answer tells you whether you are buying a company's service or one person's goodwill.
Ask about response time in plain words
Service levels are often written to sound reassuring and mean very little. Push for specifics in ordinary language:
- Our system is completely down. When do we hear from a human, and when does work start?
- Something important is wrong but we can work around it. Same questions.
- A small annoyance. Roughly how long?
- Are those hours only during the working week?
A studio that has done this before will answer immediately and will be honest about the limits. Small studios do not staff a night shift, and the good ones say so rather than promising cover they do not have.
Ask what they do proactively
The best support is the kind you never notice. Ask what happens without you raising anything at all:
- Are the servers and the framework kept patched?
- Are backups taken, and is anybody checking they can actually be restored?
- Would anybody notice the site was down before a customer told you?
- Do certificates renew on their own, and is that verified?
Every one of those has a version that sounds true and a version that is true. A system can report a successful backup for weeks while writing empty files. Ask whether anybody opens one.
Ask what happens if you leave
A company that is comfortable answering this is usually a company worth staying with. You want to hear that the code, the data and the credentials are yours, that an export is available whenever you ask, and that a handover to another developer is a task rather than a fight.
The easier a supplier makes it to leave, the less likely you are to want to.
Test it before you sign
Send a question that requires research to answer. See how long it takes, whether the reply is specific, and whether they say so plainly when the answer is no. That single exchange is the most reliable preview of year three you can get for free.
How we handle it
Support requests come through a system that keeps a record, so nothing lives only in one person's phone. Anything broken that used to work is ours to fix. New work is quoted before it starts, so there are no surprise invoices. We run daily checks on the things that fail quietly rather than loudly, including whether backups actually contain what they claim to.
We are a small team in Malé, so we do not pretend to run a night shift, and we would rather tell you that now than at two in the morning. If you want to know exactly what cover looks like for something you are planning, ask us and we will put it in writing.