Victoria Onyemaechi

Problem

The senior analysts at Meridian Retail (simulated retailer) were investigating a revenue discrepancy in October 2023 and needed one verified fact before proceeding: the total number of orders placed that month. Nura Ibrahim asked for a single, trustworthy count drawn directly from the orders table using the created_at date column.

What I did

To avoid edge cases with timestamps, I used a half-open interval in the WHERE clause, filtering for created_at >= '2023-10-01' AND created_at < '2023-11-01'. This pattern captures every timestamp within October regardless of the time component, including records at 23:59:59 on the 31st. The result column was aliased as oct_order so the output was immediately readable without needing a separate label.

Outcome

Nura's team had a confirmed, edge-case-safe order count to anchor the broader revenue gap investigation.

SELECT COUNT(*) AS oct_order
FROM orders
WHERE created_at >= '2023-10-01' AND created_at < '2023-11-01';

The half-open interval ensures all timestamps within October are captured; the alias makes the single-column result self-labelling.

Next step

A useful next step would be to break the 610 orders down by status to see how many of those October orders were delivered versus cancelled or returned, which would sharpen the revenue gap diagnosis.

Problem

Nura Ibrahim at Meridian Retail wanted the sales system's reported October 2023 gross revenue of approximately 56.9 million naira cross-checked against the raw data file. The task was to sum order totals for October only using Excel, noting that amounts in the original brief were described as stored in kobo.

What I did

I built a SUMIFS formula in cell Q2 using a two-sided date boundary: =SUMIFS(I:I,P:P,">="&DATE(2023,10,1),P:P,"<"&DATE(2023,11,1)). Using DATE() rather than text strings makes the boundary logic robust to formatting differences in the date column. The file's total column was already in naira, so no division by 100 was needed, and I worked with what the file actually contained rather than applying an unnecessary conversion. The result cell was formatted with a naira currency code and the column header was labelled 'Oct 2023 Gross Revenue (NGN)' to make the output self-documenting.

Outcome

The cross-check gave Nura a file-verified gross revenue figure she could rely on as the investigation continued.

=SUMIFS(I:I,P:P,">="&DATE(2023,10,1),P:P,"<"&DATE(2023,11,1))

The two DATE() criteria create a half-open month boundary that handles month-end timestamps correctly without hard-coding date strings.

Next step

Filtering the same SUMIFS by order status would let me isolate whether the gross figure shifts materially once cancelled or returned orders are excluded.

Problem

With the revenue question still open at Meridian Retail, Nura Ibrahim needed a glanceable total she could check quickly. The request was to connect Power BI to the Meridian database, write a DAX measure converting kobo to naira, and display the result on a single card visual with a clear page title.

What I did

The DAX measure sums the total_cents column and divides by 100 in one expression: Gross Revenue = SUM('retail orders'[total_cents]) / 100. Keeping the measure to a single line with no filters means it returns an unconditional total across all orders, which is exactly what a headline card should show. The measure was formatted as Currency with 2 decimal places so the card displayed a clean naira figure. The page was titled 'Meridian Retail - Gross Revenue' to match the brief's instruction for a clear, descriptive label.

Outcome

Nura had a single-screen gross revenue figure she could check at a glance while the deeper investigation was ongoing.

Next step

Adding a date slicer or a second card filtered to a specific month would let this single page serve the October-specific revenue question as well as the all-time total.

Problem

Chidi Okafor at Meridian Retail was heading into an investor meeting and needed a mobile-readable email with three things: the clean, deduplicated customer count, one sentence explaining why that number was the right one to cite, and one sentence flagging the duplicates so no one in the room would be caught off guard.

What I did

The email led with the clean count of 2,131 in plain language, without jargon, so Chidi could read it between meetings on his phone. One sentence explained that the figure excludes duplicate records and therefore represents the trustworthy customer base. A second sentence named the 200 duplicate records explicitly, giving Chidi the context to handle any question about a larger raw total of 2,331. The structure followed a standard business format: subject line, greeting, body, sign-off.

Outcome

Chidi entered the meeting with a verified number and enough background to address any question about the raw total without being surprised.

Clean Customer Count - Pre-Meeting
Good morning, sir. The correct clean customer count is 2131, as this figure excludes the duplicate records and represents the customers not flagged as duplicates.
There are 200 records flagged as duplicates, which have been excluded from the clean customer count.

Kind regards,
Victoria

The email leads with the verified number, follows with the rationale, and closes with the caveat, matching the exact three-element structure the stakeholder requested.

Next step

A follow-up analysis could examine what the 200 duplicate records have in common, such as shared email domains or registration dates, to understand whether the duplication reflects a systemic data entry pattern.

Problem

Nura Ibrahim at Meridian Retail flagged a revenue discrepancy and assigned an initial data familiarisation task before deeper investigation could begin. The question was straightforward: what order statuses exist in the orders table, and how many orders carry each one?

What I did

I grouped the orders table by status and counted rows in each group, then sorted descending by count so the most common status appeared first. Ordering by order_count DESC was a deliberate choice: it makes the result scannable in seconds and immediately surfaces which status dominates the table. The query runs directly against retail.orders with no joins or subqueries, keeping it transparent and easy to verify.

Outcome

Nura had a complete picture of how orders were distributed across statuses, giving the investigation a clear starting point for isolating which status types were contributing to the revenue gap.

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

Sorting by order_count DESC surfaces the most frequent status first, making the result immediately useful for prioritising where to investigate the revenue discrepancy.

Next step

Filtering this breakdown to October 2023 only would show whether the status distribution that month differed from the overall pattern, which could point directly to the source of the discrepancy.