Enterprise CDP incident intelligence
Ten to twelve enterprise accounts, each generating incidents against the same platform, handled by an L1/L2 team under SLA.
PROBLEM
Incident data existed but was never aggregated. Leadership saw SLA compliance; nobody saw what the platform was actually failing at.
HYPOTHESIS
Ticket metadata alone — category, account, recurrence, resolution path — is enough to produce a product-grade signal without any new instrumentation.
RESEARCH
Built recurring reporting across SLA, transaction volume, channel consumption and year-on-year movement, then looked for categories that were both high-volume and repeat-offending.
DATA USED
Ticket metadata · SLA timers · account tiering · channel consumption · resolution categories
DECISION MAKING
Used reopen rate rather than raw volume as the prioritisation signal — a high-volume category with clean resolutions is operational, but a reopening category is a product defect.
SOLUTION
A standing incident-intelligence report circulated to product and engineering, with the top recurring categories named explicitly each cycle.
BUSINESS OUTCOME
Fed 15–20 prioritisation decisions and product fixes over the year, sourced from support data rather than roadmap intuition.
REFLECTION
This is the work that convinced me the analyst role was already the job. The title just hadn't caught up.
SQL INVESTIGATION
SELECT category,
account_tier,
count(*) AS tickets,
avg(resolution_minutes) AS avg_res,
sum(CASE WHEN reopened THEN 1 ELSE 0 END) AS reopens
FROM incidents
WHERE created_at >= date_trunc('quarter', now())
GROUP BY category, account_tier
ORDER BY tickets DESC;