Managed support
Ongoing support for your production systems from engineers who know them.
ALGOFACT provides managed support for the applications it built or took over after a technical review, and for the infrastructure they run on: monitoring and alerting, security patching, bug fixes, backup checks, capacity tracking and small enhancements. Service levels, working hours and on-call coverage are written into each contract according to how critical the system is. Support is delivered by an embedded team of engineers who know the system, working from our offices in Adana and Ankara TEKMER, Türkiye.
At a glance
Last updated:
- Scope
- Applications, databases and cloud infrastructure
- Systems covered
- Built by ALGOFACT or taken over after review
- Service levels
- Set per contract by system criticality
- Model
- Embedded team that knows the system
- Reporting
- Periodic incident and change reports
- Information security
- ISO 27001:2022 access and change management
When is managed support the right model?
Much of the work on a system starts after it goes live: security patches, certificate renewals, disks filling up, queries slowing down, integrations changing and bug reports from users. Building a full-time team for that is not sensible for every company, and handing it to a help desk that has never seen the system makes every problem last longer.
Managed support means the engineers who built the system, or who learned it through a structured takeover, keep running it. Knowledge lives in runbooks and records rather than in people’s heads, so support continues even when the team changes.
Our focus is applications and the infrastructure under them. Desktop IT, such as office networks, end-user laptops or printers, is not the center of this service; if you need it, we discuss it separately in the discovery call.
What support covers
Scope is written per system; most agreements combine these tasks.
- 01
Monitoring and alerting
Application, database and infrastructure metrics, error rates and business-critical flows such as payments, sign-in or integrations are monitored, and alerts are routed to the on-call engineer. - 02
Patching and version upkeep
Operating system, runtime, library and database updates are tried in a test environment first and applied in planned maintenance windows. - 03
Bug fixing
Issues from users or monitoring are prioritized, traced to their root cause, fixed, tested, released and recorded in the incident log. - 04
Backup and restore checks
We do not assume backups work. Regular test restores confirm that backups can actually be used. - 05
Capacity and cost tracking
Data growth, traffic and the cloud bill are watched, and we propose action before a bottleneck or wasted spend appears. - 06
Small enhancements
Requests such as a screen, report or integration change are scheduled within the development capacity set aside in the contract.
Takeover and operations
- 01
Takeover review
If another team built the system, we first review the code, infrastructure, access, documentation and open bugs. Fixes needed to make it supportable are planned as a separate onboarding job. - 02
Access and knowledge transfer
Access is tied to roles rather than individuals, critical knowledge is written into runbooks and missing monitoring is put in place. - 03
Writing the service levels
Priority classes, working hours, on-call coverage, communication channels and reporting are defined together in the contract. - 04
Day-to-day operations
Incidents, changes and maintenance are tracked in a ticketing system. After every serious incident, the root cause and a preventive step are written down. - 05
Regular reviews
Incident trends, open risks, capacity and the roadmap are reviewed with you in regular meetings.
What you receive
- 01
Service level definition
Priority classes, scope, working hours and on-call rotation. - 02
Monitoring and on-call setup
Health indicators, alert thresholds and how an alert reaches the on-call engineer. - 03
Support runbooks
Step-by-step procedures for common incidents, maintenance tasks and restores. - 04
Incident and change records
A timeline, root cause and fix for every incident; approval and outcome for every change. - 05
Periodic status report
Incidents, maintenance done, open risks and recommended improvements.
How service levels are set
We do not promise a response time on this page, because the right target depends on the system. A system that holds patient records or takes payments does not need the same on-call setup as an internal reporting tool used a few times a month. The contract spells out, per system, the priority classes, working hours, whether there is after-hours on-call and the communication channels.
The systems on ALGOFACT’s /work page include software that is expected to run without interruption, such as family health center management software for the Turkish Ministry of Health (Sağlık Bakanlığı), hospital management system software for Letoon and a membership dues collection system for KAFFED. In the systems we build, monitoring, logging and runbooks are ready before go-live, which makes later support easier to plan.
Access, change approval and record keeping follow our ISO 27001:2022 certified information security management system. On systems that hold personal data, engineers’ access to that data is limited to what their task requires and is logged.
Questions about managed support
Approach01Will you take over a system another vendor built?
Yes, after a takeover review. We examine the code, infrastructure, access and documentation and present in writing what is needed to make the system supportable. In some cases we recommend a substantial cleanup before support begins.
02What are your response times?
Response and resolution targets are agreed in the contract based on how critical the system is. Rather than quote a general figure, we write down what happens within which time for each priority class.
03Do you offer after-hours and weekend coverage?
For systems that need it, an after-hours on-call rotation can be added to the contract. Which systems and which priority classes it covers is defined explicitly.
04Is the support team the same as the development team?
As far as possible, yes. The engineers who built the system take part in support, which makes it easier to get to the root cause of a bug. When the team changes, knowledge passes through runbooks and incident records.
05What drives the cost of a support agreement?
The number and complexity of the systems, the working hours and on-call coverage you need, the development capacity set aside, where the infrastructure runs and the state of the system before takeover. After the review we present the scope and service level options in writing.
06What happens to the system when the contract ends?
The system and all access belong to you. Because runbooks, incident records and documentation are kept current, the handover to your own team or another vendor can be planned.
Tell us about your project
Describe the problem briefly and we will reply with a time for a 30-minute discovery call.
Book a discovery call