Managed IT services. Your environment, our responsibility.

The service is designed after discovery around the agreed environment, risks, internal capability and business objectives. It can include users, endpoints, Citrix, Microsoft 365, identity, cloud, infrastructure, security operations, backup oversight, monitoring, service management, supplier coordination and governance. The proposal and service schedule define exactly what is included and excluded.

Think Response investigates agreed requests, alerts and incidents, restores service, establishes cause and identifies the change needed to reduce recurrence. Managed Services adds continuing operational responsibility for carrying agreed actions through live operations, with retained environment knowledge, governance, reporting and continual improvement. It is not the Think Response retained-hours model.

Yes. A co-managed model can add specialist capability, operational capacity, a defined service area or 24x7 coverage while your internal team retains leadership. Responsibilities, authority, workflows and escalation are made explicit so the teams work as one rather than duplicating effort.

Yes, where discovery shows that a complete managed model is appropriate. Thintech can take day-to-day operational responsibility across the agreed users, platforms, security, support and suppliers while the customer retains ownership of its business, data, policies and strategic decisions.

No. Managed Services can operate across customer premises, customer data centres, public cloud, private cloud, Thintech-hosted services or a hybrid combination. Moving to flexiDesk is a separate platform decision, not a requirement for Managed Services.

Thintech can manage agreed services across those operating models, subject to technical discovery, access, supported configurations, location, licensing and the skills and controls included in the service. The final responsibility boundary is documented before transition.

Thintech operates a 24x7 service desk and can provide round-the-clock operational coverage. Service-desk availability, monitoring, alert acknowledgement, engineering response, on-site attendance and resolution are separate commitments. The service schedule defines which apply, to what and at which priority.

Named service management and aligned engineering resources can form part of the service. Dedicated or on-site resources are available where justified and expressly included. Thintech also shares and documents knowledge so continuity does not depend on a single named individual.

Thintech uses a controlled transition: discovery, scope and responsibility definition, technical baselining, knowledge transfer, tooling, documentation, escalation testing, service acceptance and early-life support. We do not pretend an unfamiliar environment becomes fully managed on contract signature.

It depends on service breadth, environment complexity, documentation, access, supplier cooperation, tooling, risk and any immediate stabilisation work. Thintech confirms a transition plan after discovery rather than publishing an unsafe generic duration.

Within the agreed scope, Thintech can coordinate investigation, technical evidence, escalation and communication across carriers, cloud providers, software vendors and other suppliers. Thintech cannot control a third party's repair time, product code or contractual liability.

The service can operate agreed controls across identity, endpoints, email, cloud, servers, patching, administrative access, alerts, backup and recovery. This strengthens visibility, reduces exposure and supports response and recoverability, but it cannot make cyber incidents impossible or transfer every customer risk to Thintech.

No. Thintech operates an ISO 27001:2022-certified information security management system, and its certificate scope includes enterprise IT managed services and End User Computing. Customer compliance still depends on its own obligations, people, policies, data, suppliers and risk decisions.

Backup oversight, retention, restore testing and recovery planning can be included for agreed services and workloads. The design states what is protected, where copies are held, how exceptions are handled and any recovery objectives. Disaster-recovery capacity and testing may require additional scope.

Measures are chosen around the service and decisions the customer needs. They can cover availability, priority incidents, response performance, recurring problems, change, patching, backup, security themes, capacity, risk and improvement actions. Ticket volume alone does not demonstrate service health.

Coverage, priorities, response commitments, escalation, authority, on-site arrangements and any recovery or availability objectives are designed around business need. A response target is not a guaranteed resolution time, and every service level is recorded contractually.

The service model depends on scope, users, sites, technology complexity, coverage, service levels, security and resilience requirements, aligned resources, tooling and transition effort. A Discovery Workshop allows Thintech to develop a meaningful indicative model without publishing a misleading generic price.

Yes. Many organisations start with a defined area such as Citrix, cloud operations, Microsoft 365, security oversight or 24x7 coverage. Scope can expand through governed change once responsibilities, dependencies, capacity and commercial terms are agreed.

Think Consult designs strategy, architecture and transformation. Managed Services operates an agreed live environment. Consultancy or project work can be commissioned alongside the service for material change. flexiDesk is Thintech's complete hosted IT platform and is not required for Managed Services.

Exit responsibilities, access removal, data return, knowledge transfer, supplier transition, timescales and any assistance are defined in the agreement. Managed operations should increase documented knowledge and control rather than create avoidable lock-in.