PETER DAWODU

Problem

Meridian Retail (simulated retailer) needed its brand colours applied consistently before any reports were shared externally. Chidi Okafor asked me to configure a custom Power BI theme using six specific hex codes, including a sentiment mapping for good, neutral, and bad states, and save it under the name 'Meridian Retail'.

What I did

The theme was built as a JSON configuration with the six brand colours placed in the correct order inside the dataColors array, matching the brief's sequence exactly. Sentiment colours for good, neutral, and bad were defined separately so they would apply correctly to charts tracking performance states. Alongside the theme work, Power Query transformations on the retail customers table were also in place: a boolean filter on is_duplicate, a Full Name concatenation, a conditional column for Customer Tier, and an Acquisition Year extraction. Applying the theme to a report containing both a tableEx and a clusteredColumnChart confirmed the colour changes were active across real visuals.

Outcome

Meridian now has a reusable branded theme file that can be applied to any future report, ensuring visual consistency without manual colour adjustment each time.

#"Filtered Rows" = Table.SelectRows(retail_customers, each ([is_duplicate] = false)),
#"Added Custom" = Table.AddColumn(#"Filtered Rows", "Full Name", each [first_name] & " " & [last_name])

This Power Query step removes flagged duplicate customer records before any downstream columns are built, so that the Full Name concatenation and Customer Tier logic only run on clean, unique rows.

Next step

A useful next step would be to check whether the Customer Tier conditional column boundaries produce balanced segments, or whether one tier dominates in a way that limits its usefulness for filtering.

Problem

Meridian Retail (simulated retailer) CFO Nura Ibrahim flagged a revenue discrepancy and needed a clear picture of what order statuses existed in the orders table before deeper analysis could begin. The specific question was how many distinct statuses the table contained and how many orders fell under each one.

What I did

A single aggregation query against retail.orders grouped rows by status and counted them, with the result sorted descending so the most common status appeared first. Using the explicit schema prefix retail.orders made the query unambiguous regardless of the session's default search path. Sorting by order_count descending rather than alphabetically meant the output was immediately readable for triage rather than requiring a second pass.

Outcome

The status profile gave the CFO a complete picture of order states to work from, establishing a reliable baseline before any revenue-focused filtering was applied.

SELECT status, COUNT(*) AS order_count
FROM retail.orders
GROUP BY status
ORDER BY order_count DESC;

This query counts rows per status and sorts them from most to least common, producing a result that is ready to read without any further transformation.

Next step

The logical next step would be to filter to financially material statuses, specifically cancelled, returned, and refunded, and join to order values to quantify the revenue impact Nura flagged.

Problem

FlowRoute Logistics (simulated logistics company) Head of Customer Experience Funmi Alade needed a complaint summary her team could keep updated without manual intervention. The brief asked for a total complaints figure, a category breakdown with counts and percentages sorted from most to least common, and a single cell identifying the lead category for a board presentation.

What I did

The total was driven by COUNTA referencing the full column range on the Complaints sheet, so any new rows added later would be picked up automatically. COUNTIF formulas in the category breakdown rows reference the same source range, keeping all counts live. Percentages divide each category count by the total using an absolute reference to the total cell, with an IFERROR wrapper added in case the denominator is ever empty. The board lead cell uses INDEX/MATCH against MAX of the count range rather than a hardcoded label, so it updates automatically if category volumes change.

Outcome

Funmi's team received a summary sheet with fully live formulas, meaning the headline figures and the board lead cell will update as new complaint records are added without any manual rework.

Next step

Splitting the category breakdown by hub would show whether certain hubs drive a disproportionate share of a specific complaint type, which the current summary does not reveal.

Problem

Meridian Retail (simulated retailer) stakeholder Chidi Okafor was walking into an investor meeting and needed the clean customer count in a format readable on a phone. The message had to include the figure, a one-sentence explanation of why it was the right number to use, and a caveat about duplicate records so no one in the meeting would be surprised by a different figure from another team.

What I did

The count of 2,131 came from filtering the customers table to records where is_duplicate equals false, excluding the 200 duplicate-flagged rows present in the full table. The explanation was kept to a single sentence to match the phone-reading constraint Chidi specified. Flagging the 200 duplicate records in a separate sentence gave Chidi a ready answer if another team quoted the higher unfiltered total.

Outcome

Chidi had a defensible, clearly sourced number to use in the investor meeting, along with a pre-emptive explanation for any count discrepancy raised by other teams.

Next step

It would be useful to examine the 200 duplicate records more closely to understand whether they are true duplicates across channels or data entry errors, since the answer affects how acquisition numbers should be interpreted.

Problem

FlowRoute Logistics (simulated logistics company) Head of Customer Experience Funmi Alade needed to know which hubs posed the most operational risk, without letting raw shipment volume distort the picture. The brief asked for a hub table combining delivery rates and complaint counts, a volume-normalised complaints-per-1,000-shipments metric, and an honest verdict on whether any hub truly stood out.

What I did

Hub fields were pulled with direct cell references to Hub_Performance rather than pasted values, so the table stays live if the source sheet changes. Complaint counts per hub use COUNTIF against the full Complaints sheet column, matching each hub name dynamically. The complaints-per-1,000 formula divides each hub's complaint count by its own total_shipments and multiplies by 1,000, with IFERROR protecting against division by zero. Delivery rates were divided by 100 and formatted as percentages to match the source values correctly.

Outcome

Funmi received an honest, evidence-based verdict: the data did not support singling out one hub, which prevented a misplaced operational focus and gave a more accurate picture of system-wide complaint distribution.

=COUNTIF(Complaints!$E$2:$E$1048576,A4)
=IFERROR(E4/C4*1000,0)
=Hub_Performance!G3/100

These three formulas count complaints per hub from the source sheet, convert the raw count to a per-1,000-shipments rate using each hub's own volume as the denominator, and pull the delivery rate as a true decimal for percentage formatting.

Next step

Breaking complaints per 1,000 shipments down by complaint category per hub would show whether Ibadan's marginal lead is concentrated in one failure type or spread evenly, which would determine whether the response is operational or process-related.