the contact-centre lead who built her own dashboard.

She’d put her hand up and said there was a gap in her Power BI she couldn’t close on her own. Her team was about to grow from two to three, so she’d soon be bringing new people up to speed as well, and the whole thing had been sitting on her to-do list, and her performance review, for the best part of a year.

She ran the team’s reporting out of Excel. She’d worked through the online Power BI modules and could follow them fine, right up to the point where she swapped the sample data for her own: call stats, adherence, quality scores and messages from several systems, none of which agreed on how to spell an agent’s name or which ID belonged to whom. When something broke, she’d take it to the internal data team, who’d do their bit and hand it back working - and she’d nod along without understanding what they’d done, aware she was leaning on their goodwill.

So it went in cycles. She’d have a go, get frustrated, push it away, and come back to it a couple of months later. What she actually wanted was to do something with her own data herself, and not feel like she was failing a part of her job by handing it off.

The decision that mattered was already hers: she wanted to build this herself, not be handed a report someone else had made. A classroom course was never going to get her there, because the wall she hit was the bit courses skip: her own data, in all its mess. So I pitched her learning and development manager the other way round: a long, side-by-side training-and-build. She built her actual dashboard, on her actual data, from the first session - live on calls, with me coaching her through what she was seeing and what to do about it - the whole thing paced to fit around her actual week.

The first job was untangling who everyone was: her systems each had their own version of every agent, and none of them agreed. So she built one trustworthy list of agents from the phone platform - me explaining why that list had to come first - and we used it to find the mismatches: leavers still in the call logs, the chatbot and her own name showing up where they shouldn’t. From there she grew it into a proper model: a clean set of fact tables for calls, time, messages, quality and sentiment, hung off shared agent and date tables, with the calculations written out explicitly so she could read them back.

And she did the doing. She fixed a broken query herself mid-session, and reached for the right function before I got there, recognising it from Excel. The teaching was always on the symptom in front of her: when every agent showed the same total, I showed her why the number was wrong, so she’d recognise it herself next time.

Two moments I’d point to. When a system outage dropped a 66-hour junk value into the data, I didn’t show her a quiet filter to make it disappear. The rule she got instead:

You’re always collaborating with someone, even when it’s only yourself in six months’ time, and that person deserves to be able to see the reasoning. And when she asked about modelling agents who move between teams over time, I was straight with her - a real problem, a genuinely hard one, and too big for where we were, so we’d save it. Knowing what to leave for later is part of how she ends up with a model she can keep running herself.

From Excel-only and a Power BI habit of starting and giving up, to a real, maintainable dashboard on live data that pulls together everything she used to stitch by hand - and a person who can keep it going and extend it. She left with the model documentation, a DAX reference, a refresh routine and a short list of places to keep learning. And she kept at it: she’s in Power BI most days now, and records short voice-notes to herself about it on the commute home.

This is the sort of work I do embedded with a team, month to month. what working together looks like - shape, rhythm, price ▸