Who supports the dashboards after go-live

The migration closes, the project team disbands, and the questions start. A number looks wrong. A refresh did not run. Someone new needs access. A view that worked yesterday is empty today.

In most organisations these all go to the same place, which is a direct message to whoever built it. That works for about six weeks. Then that person is on another project, replies get slower, and users conclude the platform is unreliable, which is a support failure being recorded as a product failure.

The fix is not a helpdesk product. It is deciding, in writing, which of those four questions goes to whom, and accepting that they are genuinely different kinds of work.

The fourth row is the important one and it is deliberately not a tier. It exists in the table so that everyone can see where the line is drawn, because the line will be tested in the first month.

Tier 1 is genuinely delegable if somebody writes the runbook, and writing it is a two-day job. Without the runbook the service desk forwards everything to Tier 2, and you have a two-tier model with an extra delay in it.

Access requests are cheap and platform incidents are rare. The recurring cost is the middle tier, because every question in it starts as this number looks wrong and ends somewhere unpredictable.

The reason it is expensive is that answering it requires knowing what the number is supposed to be. That is not a platform skill or a service-desk skill, it is knowledge of the business definitions, and it lives in about two people.

So invest in the thing that reduces the question rather than the thing that answers it faster. A written, agreed definition per metric turns most of these from an investigation into a lookup, which is the whole argument of metric definitions that survive a team change. Certification does the same job at the asset level, telling a user which of two similar dashboards is authoritative before they email anyone.

Track the questions for the first quarter, even crudely. Ten tickets that all trace to one dashboard is not ten support incidents, it is one content defect and nine people finding it.

A failed refresh that a user reports is a support incident. A failed refresh that the platform reports before a user sees it is a maintenance task, and the difference in cost between those two is large.

Tableau's guidance is direct about the trap: without monitoring, a set-it-and-forget-it deployment can be met with inadequate resources that fail to support the workload of highly engaged users, and ongoing proactive monitoring is required to operate a deployment at scale. It also makes a point worth repeating to sponsors: it is as important to monitor for things going right as for things going wrong, because rising adoption is itself a capacity event.

The same page describes the useful habit of combining monitoring data with engagement data, giving the example of finding scheduled refreshes attached to workbooks nobody has opened in 180 days. That single query is both a cost saving and a reliability improvement, and it takes an afternoon.

Microsoft frames the equivalent function as system oversight, defined as the ongoing day-to-day administrative activities covering governance, user empowerment and adoption. The framing is useful because it makes clear this is a standing function with an owner, not a set of tasks that get done when someone notices.

Two operational surfaces generate a disproportionate share of support load, and both are configuration rather than engineering.

The first is refresh scheduling. Tableau lets you set refresh schedules for published data sources and workbooks, including the frequency and the time they run. The common failure is not a wrong schedule, it is that everything was scheduled for the same hour during the migration and never revisited. Stagger by business need, so the dashboard opened at eight refreshes before the one opened at noon.

The second is subscriptions. These email an image or PDF snapshot of a view or workbook at regular intervals without requiring the recipient to sign in, which makes them the most-used feature by the least-visible audience. The documentation lists the sending domain and IP addresses that must be permitted by corporate mail filtering, and notes that undeliverable subscriptions can result in the recipient being temporarily blocked.

That detail is a support model issue rather than a technical one. If subscription email silently stops for an executive because a mail filter changed, nobody raises a ticket, because from their side nothing happened. Put a check for delivery failures on the monthly maintenance list.

Data freshness expectations should be written down alongside all of this. What counts as late, and who is told, is a decision that belongs in a data freshness service level for reporting rather than being improvised per incident.

Access requests are individually trivial and collectively the largest count of tickets in year one, especially in an organisation with turnover.

They are also the most automatable. Tableau's REST API includes methods to add users to a site, assign site roles, create groups and manage group membership programmatically, which is enough to drive provisioning from the directory rather than from an inbox.

The design rule is the same one governance already asks for: assign permissions to groups, never to individuals, and let joining a group be the entire provisioning action. Then onboarding is one directory change instead of a ticket per dashboard.

Pin the API version in whatever you build. A provisioning script written against whichever version happened to be current is a script that breaks at an upgrade nobody scheduled, and the failure surfaces as new joiners having no access on their first morning.

A support model with roles and no names is a document. The version that works has a named person per tier, a named owner per significant dashboard, and a stated cover arrangement for holidays.

It also needs a stated volume of time. Support that is expected to happen in the gaps of someone's day happens in the gaps of someone's day, which means it happens after the urgent project work, which means it does not happen. Half a day a week, visible in the plan, is more honest than an unbounded expectation.

Cost this before go-live, not after. It is a recurring line and it does not appear in a conversion estimate, which is one of the reasons the total cost of a platform move is routinely understated in the way that cost models get built.

Then read the support queue as adoption evidence. Questions arriving means the platform is being used; questions stopping while usage stays flat means people gave up. The measures that separate those two cases are in BI adoption metrics worth tracking.

On an enterprise transit programme where 154 data sources migrated with zero unplanned production outages, the handover to an internal team that had never run a platform migration was as much a part of the delivery as the cutover itself. That is the last obligation of a BI platform migration: leaving behind an environment somebody can actually operate.