When does your business need technical support?
Your newsletter has just gone out and the online shop slows down. Or the integration suddenly stops passing orders on. At that point you no longer wonder whether technical support is needed. You want someone on the line who knows the setup and fixes the problem.
Even so, I would not recommend an ongoing support contract to every business. For a simple website without integrations, with little traffic and limited commercial weight, you mostly pay for certainty you don't use. If orders or partner integrations run on your systems, I would recommend a dedicated technical partner.
Where that line falls depends on what happens when a system goes down or becomes unreliable.
You need technical support where downtime costs money
The best yardstick is what an hour of downtime costs at the worst moment you can think of. Your online shop being unreachable for an hour on a quiet Tuesday: annoying, perhaps manageable. If the same environment fails while a newsletter, campaign or TV spot is sending visitors, customers give up and your campaigns keep pointing at a site that is unreachable.
An outage in an internal portal may stay invisible to customers while it brings planning or invoicing to a halt, after which colleagues take over the work by hand. And in the meantime you are not sure all data was processed correctly.
A check you can do today: for each system, write down which processes run on it, how long it can be down at most and who notices first. If you hesitate on any of those answers, your business probably leans on that system more heavily than you thought.
Integrations turn an outage into a search
In growing businesses, integrations often pile up gradually. It starts with a website that works well. Then a payment provider, stock software, a CRM and marketing tools are added, and sometimes a custom portal or a mobile app.
In a setup like that, an outage is rarely an isolated problem. An error message in the app can come from hosting capacity, a database query, a changed integration or an update at an external service. Without a party that knows the whole picture, precious time goes on working out which supplier to call. The host points at the developer, the developer at the API, and internally nobody knows who is in charge.
This is where I would spend the money: on one partner with a view of development, infrastructure and integrations. Such a partner can investigate the cause and organise the repair, and that is what you are paying for. I would make the same choice if your customers expect everything to be reachable at all times, or if your own team has no time to assess alerts.
On-call support works if the basics are proven
If you run a clear, stable application that changes little and touches no business-critical processes, I would skip the ongoing support agreement and go for periodic maintenance, proper back-ups and a contact who is reachable when something happens.
Maintenance is still needed. Browsers, mobile operating systems and security risks keep changing, and a solution that works well today may, six months from now, depend on an outdated component or on an external API that behaves differently.
You pay for this choice in preparation. On-call help only works if the person you call can get started straight away. Go through these points:
- Can you log in to the hosting and the admin environment with the credentials you have now?
- Has a back-up ever been restored to check that recovery works?
- Is it written down somewhere which software and integrations you use?
An emergency number without documentation and without access to the right environment is not a continuity plan.
Also make sure someone inside your business decides what counts as urgent. An error in the payment step gets picked up immediately; a button that is misaligned on one page can wait. Agree in advance on severity levels, how you reach each other and the expected response time. That saves frustration on both sides.
Agree the route before discussing 24/7
Whether you want 24/7 support is the last question I would ask. Start with the moments when your systems must not fail. A consumer platform that takes revenue in the evenings and at weekends needs different arrangements from a B2B portal used only during office hours.
A response time on paper means little if nobody knows how an outage reaches the right person and what they may do. So discuss these with your partner:
- Is an outage monitored before customers call?
- May the partner step in directly, or is internal approval needed first?
- Who are the current contacts for urgent issues?
- Which recovery actions are approved in advance?
Also note who manages the hosting, who monitors performance, who owns the source code and the access credentials, and who picks up an incident when an external integration fails. You answer those questions on a quiet Tuesday. During an outage you are too late.
Keep three terms apart in the agreement. Availability is about whether your system is running. Response time is about when someone picks up the incident. Resolution time depends on the cause and cannot always be promised exactly in advance. A reliable partner is honest about that and keeps you informed along the way.
Recovery is only half the work
Speed matters during an outage, and sometimes a temporary fix is needed to get your processes running again. After that, someone has to find out why it happened and whether a structural improvement is needed. If that does not happen, you pay for the same problem several times.
Ask for an explanation in plain language while you are at it. A technical story without a clear course of action does not help an operations manager. You want to know the impact and which decision lies with you.
There is work to do outside outages too. A platform can be online and still cost revenue because pages load slowly at busy moments. Postponing updates because everything works right now feels efficient until someone exploits a vulnerability. Watch out for the other extreme, though. Unnecessary changes carry risk and cost too, so do what stability and security require and leave the rest.
Tell your partner what is coming
A product launch, seasonal peak, new integration or growth in users needs preparation. If you only sort out capacity, error handling and monitoring after go-live, you make the risk needlessly large.
Your partner only sees those moments coming if you share them. A marketing campaign can have big technical consequences. A new supplier can affect an existing integration, and after an internal process change a tool sometimes has to do something other than what it was originally built for.
One owner inside your business is enough for this: someone who translates business priorities into what is needed technically. The partner then looks after execution and risk. If you work with custom software, apps, integrations and hosting at the same time, one technical point of contact is often the most practical. At LJPc, development and infrastructure sit close together, so investigation and repair stay with the same party.
This week, open your calendar and find the next moment when your systems must not falter, such as a promotion or the busiest period of your year. Write down who would spot an outage first and who is allowed to step in. If you cannot fill that in, discuss it with your technical partner or contact before that date arrives.