If you have ever inherited a Power BI file where every measure is a mess of nested IF statements and nothing quite adds up between tabs, there is a good chance the real problem was never the DAX. It was the model underneath it.

I have seen this pattern over and over in service and contact-center reporting. Someone builds a report by dragging fields straight out of one flat export (calls, tickets, whatever the source system spits out), the first few visuals look fine, and then three weeks later someone asks “why does average handle time look different on this page than on that one” and nobody can explain it. Usually the answer is that the model was never really a model. It was one wide table pretending to be one, and every measure had to compensate for that on its own.

So before I touch a single DAX formula on a new contact-center dashboard, I spend time on the semantic model. Here is how I approach it.

Start by separating facts from dimensions

A contact-center dataset is full of things that change every day (calls, tickets, chats) and things that stay mostly fixed (agents, queues, channels, SLA targets). Those need to live in different tables.

My starting point is almost always:

A fact table for interactions: one row per call or ticket, with foreign keys to date, agent, queue, and channel, plus the numeric fields you will actually aggregate (handle time, wait time, resolved flag, CSAT score if you have it).
A Date dimension, built properly with a continuous calendar, not just the dates that happen to appear in the data.
An Agent dimension, with attributes like team, tenure, shift, and site if relevant.
A Queue or Skill dimension, since most contact centers route by queue and leadership wants to compare queues against each other.

This is a star schema, and yes, it is the boring textbook answer, but it is boring because it works. Once your fact table only holds numbers and keys, and your dimensions only hold descriptive attributes, filtering and slicing behave the way people expect them to. Click on a queue in a slicer and every visual on the page responds the same way, because every visual is pulling from the same relationships instead of running its own private logic.

Get the grain right before anything else

The single most important decision in a contact-center model is the grain of your fact table, meaning what one row actually represents. Is it one row per call? Per call segment (if calls get transferred)? Per ticket status change?

I have seen dashboards break because someone mixed grains without realizing it, for example loading both “one row per call” and “one row per call event” into the same table. The moment you sum a column across mixed grains you get numbers that look plausible but are wrong, and that is worse than numbers that are obviously wrong, because nobody catches it.

Decide the grain up front, document it somewhere (even just a comment in Power Query), and keep every transformation downstream consistent with it. If you need a different grain for a specific analysis, like call segments for transfer analysis, build a separate fact table for it rather than bending your main one.

Build a proper Date table, always

I know this gets repeated in every Power BI article ever written, but for contact-center reporting it matters more than usual, because so much of what leadership wants is time-based: month over month trends, day-of-week patterns, intraday volume by half-hour interval.

A few things I always add to the Date table for this context:

A Fiscal period column if the business does not run on calendar months.
A Day Type or Business Day flag, since call volume and staffing plans usually only make sense compared against working days.
If intraday analysis matters, a separate Time dimension (by 15 or 30-minute interval) rather than trying to force time-of-day logic into DAX at query time.

Mark it as a proper date table in Power BI (Mark as Date Table), and relate everything through it. Do not let each fact table carry its own ad hoc date logic.

Keep relationships single-directional where you can

Contact-center models tend to accumulate a lot of relationships fast: interactions to agents, agents to teams, interactions to queues, queues to channels, interactions to dates. It is tempting to make everything bidirectional so that filtering “just works” from any angle. Resist that.

Bidirectional relationships are useful in specific, deliberate cases (like a many-to-many bridge table between agents and skills, if agents can belong to more than one skill group). Everywhere else, single-directional filtering from dimension to fact keeps your model predictable and a lot easier to debug when a number looks wrong. If you need a filter to propagate the other way for one particular visual, handle it inside a measure with CROSSFILTER rather than making it the model default.

Design for the measures you will actually need

This is the part people skip. Before building the model, I write out (on paper or in a notes app) the list of KPIs the dashboard needs to deliver: average handle time, service level, abandonment rate, first contact resolution, occupancy, whatever applies. Then I check whether the model, as designed, can actually support each one cleanly.

Some KPIs need more than the interaction fact table gives you. Service level, for example, usually needs both an interactions table and a separate table of interval-level staffing or volume targets, because “percentage of calls answered within X seconds” is really comparing two different granularities. If you do not plan for that up front, you end up bolting on a second, incompatible table later and writing increasingly awkward DAX to reconcile them.

Working backward from the KPI list to the model design saves you from rebuilding the whole thing three revisions in.

A model that holds up

None of this is complicated in isolation. Star schema, one clear fact table per grain, a real date table, deliberate relationships, and a model designed around the KPIs you actually need to report. What makes the difference is doing it before you write a single DAX measure, not after the dashboard is half built and something already looks off.

Get the model right first, and most of your DAX formulas end up shorter and more obvious than you would expect. The measure does not have to compensate for the model’s mistakes, because there are none to compensate for.

If you are staring at a Power BI file right now where the numbers do not add up between pages, it is worth checking the model before you touch another measure. Most of the time, that is where the real problem is hiding.