Run critical technology reliably. Improve it continuously.
Support that only closes tickets keeps a platform alive without improving it. INFOC operates applications, cloud, security, data and AI under one model, with named owners, service levels and a visible improvement backlog.
SERVICE TOWERS
One accountable model across the Microsoft estate
One accountable model, sized to business criticality.
Business Applications
Business Central, Dynamics 365, Power Platform, extensions, integrations, environments, release and user support.
Cloud & Modern Work
Azure, Microsoft 365, identity, endpoint, backup, collaboration, licensing and cost operations.
Security Operations
Security posture, alerts, vulnerability, access, protection policy, investigation coordination and reporting.
Data & AgentOps
Fabric pipelines, semantic models, Power BI, AI agents, tracing, evaluation, incidents, cost and change.
Mobile workforce
APPLICATION MANAGEMENT
Protect the transaction system and extension lifecycle
ERP support must understand posting consequence, beyond closing tickets.
Incidents & requests
Prioritisation, triage, diagnosis, workaround, resolution, communication and knowledge capture.
Release & update
Microsoft releases, extension compatibility, sandbox validation, regression testing and deployment.
Integration operations
Message health, API changes, failures, retries, ownership, reconciliation and partner coordination.
Data & control
Posting issues, period locks, master data, number series, permissions, audit evidence and reconciliations.
Optimisation
Performance, process friction, automation, reports, roles, extension debt and adoption backlog.
Roadmap
Quarterly platform decisions, capability releases, AI opportunities, risk and investment sequence.
CLOUD & WORKPLACE OPERATIONS
Observe cost, health, security and user experience together
Separate dashboards hide the problem that spans all four.
Operational coverage
- Azure health, backup, capacity, availability and cost
- Microsoft 365 service, collaboration and licence operations
- Identity lifecycle, privileged access and conditional-access review
- Endpoint posture, application deployment and update coordination
- Security configuration, alert handling and incident coordination
- Vendor, provider and third-party support management
DATA PLATFORM & AGENTOPS
AI services need production operations
Agents drift. Deployment is not completion.
Pipeline monitoring, freshness, quality, schema change, reconciliation, access and capacity.
Tracing, task success, quality evaluation, safety, tools, latency, cost, feedback and regression.
Approval, escalation, exception queues, incident ownership, rollback and change authorisation.
SERVICE OPERATING MODEL
Make responsibility and escalation explicit
The boundary is documented before transition, not after an incident.
Platforms, companies, environments, users, integrations, hours and exclusions.
Priority, response, resolution targets and reporting cadence.
RACI across INFOC, customer and third parties for each service.
Knowledge capture, access, runbooks and controlled handover.
Service reviews, risk, change authorisation and roadmap.
Backlog, automation, optimisation and measured outcomes.
SERVICE LEVELS
Priority is set by business impact, not by how loudly it was raised
Written definitions, so nobody argues about severity mid-incident.
P1 · Business stopped
Production is down or financial posting is blocked. No workaround. Escalation begins immediately and continues until service is restored.
P2 · Business degraded
A core process is impaired or a workaround exists but is not sustainable. Worked in business hours with a named owner and a stated target.
P3 · Contained fault
A defect affecting individual users or a non-critical process. Scheduled into the queue and reported at the service review.
Change requests
New reports, configuration, extension work and integrations. Estimated, approved and released through the same pipeline as project work.
Coverage window
Business hours as standard, with extended and follow-the-sun options where the operation genuinely runs outside them.
Named escalation path
A service owner on our side and a business owner on yours, both named in the agreement, both reachable without going through a queue.
Response and restoration targets are agreed per contract against your coverage window, criticality and environment, then reported against monthly. We set them during transition once we have seen the estate, rather than publishing a headline number that would have to be qualified for every client who reads it.
TAKING OVER AN ESTATE
Four weeks to knowing what we are responsible for
Most transitions fail on access and undocumented behaviour, not on skill.
WEEK 1
Discovery
Environment inventory, extension and integration catalogue, open defects, scheduled jobs and the shadow processes nobody documented but everyone relies on.
WEEK 2
Access and control
Admin access transferred properly, service principals inventoried, credentials rotated, and the accounts belonging to people who left quietly removed.
WEEK 3
Runbooks
Period close, month-end jobs, recovery steps, escalation contacts and known workarounds written down in a form someone other than the author can follow.
WEEK 4
Live handover
Service commences with a risk register, a prioritised remediation backlog and an agreed first review date. Inherited problems are visible from day one, not discovered at month three.
TAKING IT OVER
Inherited environments, coverage and proof of value
Can you support what another partner built?
Yes, and roughly half of what we run we did not build. Transition captures the environment, the extensions, the integrations and the undocumented behaviour before service starts. We will tell you plainly what we found, including where the previous build makes support harder, without making that a condition of taking it on.
Do you cover AI and data platforms?
Yes. Pipelines, semantic models, capacity and agents come under the same model as the applications: monitored, changed through a pipeline, and reviewed. AI in production needs operations more than most things, because quality degrades quietly rather than failing loudly.
How is value shown over time?
A monthly service review covering incidents against target, the improvement backlog, capacity and cost, and posture. The improvement backlog is the part that matters. Support that only closes tickets keeps a platform alive without making it better, and after two years that difference is very visible.
What is not included?
Anything outside the agreed scope of environments and applications, hardware, third-party software we have no access to, and change requests beyond the agreed monthly allowance. Those are estimated and approved separately rather than absorbed silently, so the service does not quietly become a fixed-price development contract.
Can we keep some things in-house?
Yes, and many clients should. A common split is that your team owns business configuration and first-line user support, while we own the platform, the extensions, the integrations and second line. What matters is that the boundary is written down and both sides can name who owns a given failure.
How do we exit if it is not working?
Notice period as agreed, then handover of documentation, runbooks, access and source. The runbooks written during transition are yours throughout, not held as a retention mechanism. A service that depends on making departure painful is not a service worth selling.
NEXT STEP
Tell us what you are running today
Whoever built itA team and an individual, transition starts by capturing what exists before anything changes.