Ongoing support and technical maintenance for live systems

Ongoing project support

Ongoing support covers live online shops, sales platforms, dedicated web systems and applications that are already being used by customers, employees or other groups of users. As part of ongoing support, we deal with system issues, minor changes, updates, fixes, configuration, and day-to-day development and technical support.

Most commonly, these are tasks relating to an existing solution and how it currently works. This might mean updating a module or plugin, fixing a bug, changing a configuration, tweaking a small element on the site, changing some text, or resolving an issue with an existing feature, integration or server performance. Ongoing support therefore doesn't just mean reacting to failures. It also covers situations where a company wants to quickly change a specific element of a live system.

This matters especially for shops and systems that are part of a company's day-to-day operations. Even a small change may be needed because of sales, customer service, legal requirements, integration behaviour or the way a team works. Being able to commission such a change without starting a separate project makes it possible to keep the system aligned with the company's current needs.

The client doesn't need to know the technical cause of a problem. They might simply say they can't perform a particular action, that a specific message is appearing, or that a certain feature has stopped working. We then check what's happening on the technical side. We can retrace the user's journey, check the configuration, logs, integrations, module behaviour or other parts of the system, and then identify the cause and the way to fix it.

When dealing with issues affecting an existing feature, we try to identify the root cause first, rather than just removing the visible symptom. The problem may stem from, for example, an update, a configuration issue, a module, an integration, changes on an external provider's side, or the infrastructure. Identifying the source of the problem helps avoid a situation where a symptom that's been temporarily removed comes back after the next update or affects other parts of the system.

If a solution requires involving another company – for example, a hosting provider, payment operator, ERP system, courier company or module vendor – we can contact their support team and help manage the whole process. This means the client doesn't have to work out which company is responsible for a given problem or pass technical information between several suppliers themselves.

Ongoing support mainly covers smaller tasks that affect the current state of the system. However, there's no rigid line between ongoing support and project development. A minor update might be handled as an ongoing task, while a larger update to the platform, PHP or a key component may require broader work and be treated as project development.

Similarly, changing some text might be a simple ongoing task, whereas building a new section, feature or integration would be treated as a separate development task. If the scope of work goes beyond a simple change or requires broader analysis, we let the client know and agree on how to proceed.

1. Contact and raising issues

The ways to contact us are direct. Clients can call us, send an email, or raise an issue directly in the Sopchy Panel.

When a technical issue is raised through the panel, it goes straight to the person handling that particular area. The client doesn't have to wait for the request to be passed on by customer service. This matters particularly for technical problems, where getting verification started quickly is important.

Clients can choose the method of contact that suits the situation. If a matter needs discussing quickly, they can call. If they need to share details, screenshots or information about a specific task, they can use email or the Sopchy Panel.

Raising an issue through the panel has an added benefit: it stays recorded in the project history along with comments, status, the person responsible, and the time spent on it. This means information isn't reliant solely on an earlier phone call or email exchange.

2. Priorities and response times

We agree priorities together with the client. We don't sort requests purely on the basis of whether it's a critical bug, how big the change is, how long it will take, or whether the client is new or has been working with us for years.

When deciding on the order of work, we take into account how important a given task is for the company. A task that's technically a small change may be of great business significance to the client.

For example, the fact that the shop isn't down doesn't mean an issue isn't important. If a client needs to change some information in the footer for legal reasons, this may be urgent for them even though the shop is working properly. In such cases, we treat it as an urgent task.

Response times for ongoing matters can be as little as 5 minutes. During working hours, if an urgent issue comes up, we try to find someone who can deal with it straight away. This also applies to larger problems, where a fast response matters for the project to keep running.

This doesn't mean every request is guaranteed a response time under 5 minutes. Formal response times and the scope of the SLA are agreed individually with each client. A fast start to verification also doesn't mean the problem is fixed instantly. The cause of a failure may require analysis of code, logs, configuration, infrastructure or an external system.

Under standard cooperation, we don't push ongoing matters back to the following month just because other tasks have come up. During working hours, clients can get in touch with us, and we'll let them know when we'll deal with a given matter. If something is urgent, we do our best to handle it as quickly as possible.

If solving a problem requires longer analysis, we let the client know what's been checked and when we'll provide the next update. This way, the client knows the issue has been taken on and is being worked on, even if it can't be resolved within a few minutes.

3. Uptime Monitoring

As part of ongoing support, we can also monitor the availability of a website or online shop. Monitoring can cover the entire service or selected, key subpages, such as product pages.

The monitoring system checks whether the website or a specified element is responding correctly. If an availability problem occurs on the server side, a notification is automatically sent to Sopchy and the client.

Monitoring can carry out further availability checks and send additional notifications if the problem persists. We agree the checking frequency and alert conditions with the client.

Monitoring is particularly important for shops and systems where downtime can directly affect sales or business operations. It allows us to start investigating a problem before the client or a user even reports that the site isn't working.

If there's a brief server outage and the site is back up within a few seconds or minutes, the issue may resolve itself without requiring our intervention. If the downtime persists, we investigate the cause. In long-term collaborations, we can also respond to such situations in line with the agreed scope of support.

For example, if monitoring detects an HTTP 500 error, we may start by checking the logs and elements that could have caused the problem. If a faulty module turns out to be the cause, in certain situations we may temporarily disable the problematic element to restore the system's operation, and then carry out the proper fix.

4. Updates, optimisation and integrations

Ongoing support can include updates to modules, plugins and other system components. Before carrying out a major update, we check its impact on the project's operation.

If updating one element requires a change to PHP, the platform or other dependencies, we analyse the full scope of the work rather than making the change without considering its consequences.

For example, a module update may require a newer version of PHP, while the current version of the project depends on an older environment. In such a case, simply updating the module may not be possible without changes to other parts of the system.

In such situations, we check the dependencies and present the client with possible solutions. If continuing to add changes to an old project is no longer cost-effective, we may also recommend rebuilding part of the system or creating a new project.

This approach helps avoid situations where a single update causes problems with other shop functions or creates further technical dependencies.

Ongoing support can also include optimising the performance of an existing solution. If a shop or system is running slowly, we analyse the cause of the problem. Depending on the situation, we may optimise code, remove unnecessary modules, change configuration, improve how integrations work, or recommend migrating to different infrastructure.

We don't assume from the outset that slow performance means the server needs to be changed. We first check what is actually causing the problem, as the cause could be the code, configuration, database, a module, an integration or the infrastructure.

As part of our support, we can also investigate issues related to integrations. If data exchange between the shop and an ERP, payment system, courier company, BaseLinker or another system stops working, we check at which stage the problem occurs.

If the cause lies with an external provider, we can contact their support team. If the problem lies with our own solution, we carry out the appropriate fix. This distinction helps establish which element Sopchy is responsible for and which lies outside our system.

5. Security, servers and external providers

Ongoing support can also cover the security of a live project. We can check whether any suspicious files or modules have appeared in the system, analyse unauthorised access attempts or unusual traffic, and implement additional security measures where needed, such as Cloudflare.

These are actions taken in response to a specific problem or project need. They should not be mistaken for a full security audit. If a client requires a comprehensive security assessment of their system, the scope of such a service should be agreed separately.

Sopchy can also help with matters relating to servers and infrastructure, but we are not a hosting provider. Hosting and backups are typically the responsibility of the infrastructure provider.

Depending on the hosting service chosen, automatic backups may be provided, often carried out at least once a day. If a project requires additional backups or a non-standard solution, we agree the scope of responsibility and how it will be implemented on a case-by-case basis.

If server configuration changes, migration or other infrastructure-side work is needed, we work together with the hosting provider. We can help choose the right infrastructure, assess how well it suits the project, prepare technical requirements, configure the elements within our scope, and liaise with the provider's support team.

If the hosting provider offers a specific configuration or migration as part of their service, we make use of that rather than duplicating the same work. This keeps the division of responsibility between Sopchy and the infrastructure provider clearly defined.

In the case of problems with external systems, we also contact their providers directly. This may involve payment processors, ERP systems, courier companies, module providers, marketing systems or other services used by the project.

This means the client doesn't have to pass technical information between several companies themselves. Sopchy can help identify where the problem lies, gather the necessary information, and coordinate communication with the provider responsible for that element.

6. Project development and the boundary of ongoing support

Ongoing support can lead to larger development work. If, while resolving an issue, it turns out that the current solution is outdated, has technical limitations, or requires changes across several related elements, we present the client with possible options for moving forward.

We don't automatically implement every change requested by the client without first checking its consequences. If we see a solution that would be safer, simpler, or more cost-effective, we let the client know and provide our recommendation.

For example, if a client wants to update a single module, but its new version requires updating PHP and the platform, we don't treat this as a simple task of clicking "update". We first check the dependencies and determine the actual scope of work required.

Similarly, if a client wants to add a new feature that requires changes to the purchasing process, the database, and several integrations, this may be treated as a separate stage of project development.

This distinction helps the client understand whether they're commissioning a single change to a working system, or starting larger development work that requires a separate scope and estimate.

7. Documenting work and transparency of cooperation

All ongoing tasks are recorded in the Sopchy Panel. The client can check the status of a task, the person responsible, the time spent on completing it, and comments regarding the work done. They can also reply directly within the panel.

This means the history of a request remains attached to a specific project and can be referred back to later on. This is especially important for projects developed over many months or years, when it's necessary to check why a particular change was made or what caused an earlier problem.

For regular cooperation, we also hold recurring status meetings, during which we discuss completed work, current issues, and upcoming tasks.

For single or occasional requests, there's no need to arrange additional meetings. The matter can be reported directly and handled as part of ongoing cooperation.

The client should always be able to check whether a request has been received, who is handling it, what its status is, and what work has been done. That's why task information is stored somewhere accessible to the client, rather than remaining solely within the team's internal communication.

8. Forms of cooperation and billing

We carry out ongoing work on an hourly basis. The client can commission individual tasks as and when they're needed, or make use of an agreed pool of hours set aside for ongoing support.

There's no obligation to purchase a fixed subscription if the client doesn't need a regularly reserved number of hours. Tasks can be commissioned as needs arise.

The second option is a subscription with a set monthly pool of hours, for clients who want to have part of the team's availability reserved.

This approach allows the way of working together to be matched to how the system is actually used. A company that only needs occasional updates and fixes doesn't need to maintain a fixed pool of hours. A company that regularly needs support, on the other hand, can reserve the team's availability.

Working time is recorded in the Sopchy Panel. The client can check how much time has been spent on a given task and what work has been carried out.

9. Responsibility for the solution

Sopchy provides ongoing project support based on the scope of responsibility agreed with the client. If a problem arises from work carried out by Sopchy, we fix our own mistake without charging the client extra for the correction.

If a problem arises from an element outside our scope, e.g. the actions of an external supplier, infrastructure, a payment operator or a change on the side of an external system, we inform the client of the cause and the possible way forward.

Taking responsibility for a specific element of the system does not automatically mean responsibility for all external services used by the project. That's why, when technical problems occur, we establish where the cause lies and which element requires action.

We carry out development work in-house. Sopchy does not outsource development. Involving external companies may be necessary in the case of systems, services or infrastructure outside our scope, e.g. hosting, a payment operator, an ERP system or another external supplier.

Summary

The aim of ongoing support is to keep the project running and to respond to needs that arise after it goes live. The client can report a problem with an existing feature, the need for a small change, an update, or an issue with an integration, server or other element of the system.

The client doesn't need to determine the technical solution themselves. They can simply describe what they want to achieve or what has stopped working, and Sopchy will identify the cause, determine how to resolve it and carry out the work within our scope.

Ongoing support covers both minor changes and responding to technical problems, monitoring availability, updates, optimisation, support with integrations, and cooperation with external suppliers. If a task requires a larger rebuild or constitutes a new feature, it can be moved into the project development process.

For a company, this means being able to maintain and modify a working system without having to start a new project for every need. The scope of work can be adjusted to the current situation, and larger changes are separated from simple tasks when they require additional analysis, planning or testing.

Ongoing support doesn't end with simply carrying out the request. It's also important to establish the cause of the problem, determine responsibility, record the work carried out, and give the client information about the status and next steps.