Why a service level agreement (SLA)?
Over the years, we have repeatedly found that the topic of "maintenance" or "service and support" is difficult to handle for completed projects. There are several reasons for this, which we would like to explain to you below and what possibilities a service level agreement offers.
It doesn't matter whether it's maintenance and support for a TYPO3 website, a Magento store or another online project. The challenges are usually the same and can be successfully solved through a joint commitment in the form of an SLA.
The support challenge
Once a software project has been completed, an online store has been published or your website has gone live, it automatically enters the maintenance or support phase (6).
However, minor developments or unforeseeable support issues such as security updates, errors or changes in the Google index, etc. often continue to occur during this phase. A short-term response time is required.
Implementation is also expected at short notice as it is perceived as a "minor issue". Long waiting times for "little things" are met with incomprehension. Planning (1) and analysis (2) become almost impossible due to externally determined actions. Testing (5) and the actually required maintenance (6) of the basic system usually fall by the wayside. Only development (3) and implementation (4) are in the foreground.
Why is support so difficult?
Possible causes that make support tasks more difficult and their consequences:
- There isno clear "commitment" orcontractual basis for regular service, support and maintenance. Support tasks are taken for granted.
- There are no regulations for support outside core working hours, but a response is still expected.
- Service and minor development work is only called up "when required". If development resources are not called up for a long time, they are inevitably scheduled for projects in order to ensure financial security for the service provider.
- If a support case then arises, developments alreadydevelopments already planned for projects must be paused and support must be provided - preferably immediately. Both development and support suffer as a result. Support becomes unplannable.
- Updates are neglected because time is in short supply. Support is only provided on request.
- Monitoring of the software to be supported is neglected, reaction only starts when a malfunction/incident or a critical security gap occurs.
- Tasks are not carried out due to a lack of time and/or unclear boundaries ("Who is responsible for what?").
- Examples:
- Monitoring visibility on Google or Google Pagespeed and initiating measures or communication to the customer or SEO service provider.
- Assessment, planning and implementation of security updates.
- Upgrades to new, more up-to-date software versions (e.g. TYPO3 12 LTS) with dependencies on third-party software (extensions).
- Examples:
What makes a Service Level Agreement (SLA) different?
SLAs define the scope of work, define times by which work must be carried out, the scope of the work and by whom it is carried out. Tickets are sent immediately, including comments, by notification to the responsible agents, project managers or directly to support staff.
SLAs are the "fast lane" to dedicated support staff. Support employees are also "booked" accordingly during this time and are not used for projects. Regular and necessary tasks are proactively created, scheduled and carried out.
Comprehensive monitoring for application security updates, server malfunctions and resource utilization enable proactive action.
Would you like to find out more about our approach to service level agreements?
Call us on +49 [0] 21 66 . 94 04 54 or contact us using our contact form.