Skip to content
Managed service

Managed analytics and support

Monitoring, incident response and change delivery for Power BI, Fabric and Azure platforms.
  • Refresh and pipeline failures caught and fixed before the business notices
  • Small changes delivered in days rather than waiting for the next project
  • Capacity and licence cost reviewed every quarter against actual usage
  • Architecture drift surfaced early, while it is still cheap to correct

Analytics platforms rot quietly. A source system changes a column, a refresh starts failing on Sundays, a workspace fills with abandoned experiments, capacity creeps up, and the person who built it has moved on. Nothing breaks loudly enough to trigger a project. It just gets less trusted each quarter.

A managed service puts a named team on the platform: monitoring with alerts that reach a human, defined response times, a change pipeline for small enhancements so they do not queue behind the next big project, and a quarterly review of cost, performance and architecture drift.

We size it honestly. Many clients need a few days a month, not a full-time retainer, and we would rather hold a small engagement for years than oversell one and be dropped at the first renewal.

What we deliver

What the work involves

Monitoring and alerting

Refresh, pipeline and capacity monitoring with alerts routed to an on-call engineer, plus a status view your team can check without asking us.

Incident response

Tiered response times by severity, a published escalation path, and post-incident notes that record the root cause and the permanent fix, not just that service was restored.

Change delivery

A monthly allocation of engineering days for enhancements: new measures, report changes, extra sources. Tracked in your backlog with visible burn-down.

Capacity and cost review

Quarterly review of capacity utilisation, licence allocation and Azure spend against usage, with specific savings recommendations and the risk of each.

Architecture health check

Quarterly review against the documented target architecture: duplicate models, undocumented logic, security drift, deprecated features, platform changes you should act on.

User enablement

Office hours, short clinics for report authors, and refreshed documentation as the platform changes, the cheapest way to cut support volume.

Method

How the engagement runs

Each stage names the artefact it produces, so progress can be checked without a status meeting.
  1. Onboarding and discovery

    Inventory of what exists, criticality classification, access provisioning, and documentation of what we are taking on. Nothing is accepted into support undocumented.

    Service catalogue and support scope document

  2. Instrumentation

    Monitoring, alerting and the status view stood up before the service formally starts.

    Monitoring in place with tested alert routing

  3. Steady state

    Response to incidents within SLA, change days delivered against your priorities, monthly service report.

    Monthly service report with SLA performance

  4. Quarterly review

    Cost, performance, architecture and risk reviewed with your team; next quarter's priorities agreed.

    Quarterly review pack and agreed priorities

Deliverables

Deliverables

  • Service catalogue with criticality and ownership per asset
  • Monitoring, alerting and a shared status view
  • Documented SLA with response targets per severity
  • Monthly service report: incidents, changes, SLA performance
  • Quarterly cost, capacity and architecture review
  • Maintained runbooks and architecture documentation
  • Named engineers who already know your estate
Stack

Technologies

  • Power BI Service
  • Microsoft Fabric
  • Azure Monitor
  • Log Analytics
  • Fabric Capacity Metrics
  • Azure DevOps
  • Power Automate
Questions

Managed service: common questions

Standard tiers are one business hour for a critical incident (a board-level report or regulatory return unavailable), four business hours for high, and next business day for standard requests. Out-of-hours cover for overnight refresh windows is an option where the business case justifies it. We agree severity definitions with you during onboarding so there is no argument about what counts as critical at the point of the incident.

Yes, after an onboarding assessment. We need to know what we are accepting responsibility for, and you need to know what we found. Occasionally the assessment concludes that something must be remediated before we can meaningfully support it; in that case we quote the remediation separately and you decide.

A monthly fee covering monitoring, incident response and a fixed number of change days, sized to your estate. Unused change days roll over for one month so you are not pushed into make-work. Everything is on a twelve-month term with quarterly reviews and documented exit assistance. We are not interested in holding clients through switching costs.

Usually we complement it. The common pattern is an internal analytics team that owns business engagement and report building, with us covering platform operations, out-of-hours response and deeper engineering work. Where there is no internal capability we can run the whole thing, but we will also help you hire, because that is often cheaper for you long term.

You get a documented handover: runbooks, architecture documentation, monitoring configuration, open issues and credentials transfer, with a transition period included in the contract. Exit assistance is written into the agreement rather than negotiated at a bad moment.

Next step

Managed service: what the next step looks like

A two-week onboarding assessment that sets the scope honestly before anything is signed

Answered within one working day, by the engineer who would do the work