Summary
A demonstration analytics platform that transforms a synthetic ticket dataset into SLA, backlog, MTTR, risk, and root-cause indicators.
Project case study
- Demonstration project
- Synthetic data
- No live ITSM integration
Support SLA Intelligence Hub
Operational BI for SLA, backlog, and incidents.
Private source codeVerifiable technical evidence is documented in this case study.
Overview
Problem
Support operations may face fragmented data, limited visibility into SLA breaches, and difficulty prioritizing critical tickets.
My role
Indicator definition, scenario modeling, interface development, visualization implementation, and technical documentation.
- tickets with business-hours SLA
- 780
- Published home page / computed over 780 synthetic tickets / 13 Oct 2026
- SLA met
- 29.0%
- Published home page / computed over 780 synthetic tickets / 13 Oct 2026
- Backlog tickets
- 90
- Published home page / computed over 780 synthetic tickets / 13 Oct 2026
- Average MTTR
- 16h 44m
- Published home page / computed over 780 synthetic tickets / 13 Oct 2026
Data and assumptions
The 780 tickets are synthetic, deterministic, and contain no real personal data. The seed can persist the same records in PostgreSQL without changing their simulated nature; there is no active integration with an ITSM platform.
- Volume
- 780 synthetic tickets
- Granularity
- One record per ticket
- Persistence
- Local mock or PostgreSQL seed
Data structure
Modeled entities
- Ticket: protocol, dates, unit, region, category, root cause, technician, priority, impact, urgency, and status.
- SLA: first-response and resolution targets, calculated times, and compliance flags.
- Operation: channel, assigned team, vendor dependency, reopening, reassignment, and recurrence.
- Organization: demonstration tenant used to isolate the persisted dataset when the database is active.
Solution architecture
The flow keeps data, contracts, rules, and visualization separate so the demonstration source can be replaced without rewriting indicators or components.
Deterministic synthetic data
Catalogs, SLA policies, and the generator in src/data produce a reproducible dataset; the seed can copy the same records into PostgreSQL.
Data contract and access
The Ticket type standardizes each record, while the repository layer selects mock or database and normalizes both to the same contract.
Transformation and rules
Pure functions in src/lib apply filters, groupings, SLA, backlog, MTTR, recurrence, trends, and risk scoring.
Aggregation and delivery
tRPC routers and Route Handlers reuse the same functions to deliver summaries and series to the product's different views.
Executive and operational dashboard
Next.js and Recharts components organize KPIs, charts, filters, tables, and exports across executive, operational, SLA, and root-cause views.
Indicators and business rules
The definitions below match the functions and rules documented in the repository. No formula was added only for the portfolio.
| Definition | Unit | Calculation rule | Use | Limitation |
|---|---|---|---|---|
| SLA compliancePercentage of tickets with an applicable resolution SLA marked as met. | % | Tickets with resolutionSlaMet = true ÷ tickets where resolutionSlaMet is not null. | Monitor resolution deadline compliance in the scenario. | The historical view uses synthetic targets and times; Analytics v2 provides a complementary business-hours view. |
| BacklogTickets in open, in-progress, pending, or awaiting-vendor status. | Tickets | Count of records that belong to the four open statuses. | Evaluate pending workload and aging distribution. | Represents a snapshot at the demonstration dataset's fixed clock. |
| MTTRAverage resolution time for resolved or closed tickets. | Minutes or hours | Average resolutionTimeMinutes for tickets with a recorded resolution. | Compare resolution efficiency across filters and dimensions. | Times are generated by the synthetic scenario, not measured in a live operation. |
| At-risk ticketsOpen tickets with resolution deadline consumption between 75% and 100%. | Tickets | Elapsed minutes ÷ resolutionSlaMinutes, including consumption greater than or equal to 75% and below 100%. | Demonstrate preventive prioritization before a breach. | The historical rule uses elapsed minutes; the v2 layer also calculates risk in business hours. |
| Operational severityCritical-ticket slice based on P1 and P2 priorities. | Tickets | Count of tickets where priority equals P1 or P2. | Highlight tickets with higher potential impact. | Priority is assigned by the synthetic generator, not by real human triage. |
| ProductivityOperational profile by technician with open, closed, overdue, SLA, and reassignment measures. | Counts and percentage | Groupings by technician; there is no single productivity score. | Analyze workload distribution without reducing performance to one metric. | Technicians and workload distribution are entirely synthetic. |
| RecurrenceTicket with a previous occurrence in the same unit, category, and root cause within 30 days. | % and tickets | Recurring tickets in the window ÷ total filtered tickets. | Identify repeated patterns that warrant root-cause investigation. | The rule depends on the three available dimensions and configured window. |
| Root causeTicket distribution by the consolidated rootCause field. | Tickets | Count grouped by rootCause value. | Locate concentrations and guide investigation in the scenario. | Causes are synthetic categories, not conclusions from a real investigation. |
SLA compliance
Percentage of tickets with an applicable resolution SLA marked as met.
- Unit
- %
- Calculation rule
- Tickets with resolutionSlaMet = true ÷ tickets where resolutionSlaMet is not null.
- Use
- Monitor resolution deadline compliance in the scenario.
- Limitation
- The historical view uses synthetic targets and times; Analytics v2 provides a complementary business-hours view.
Backlog
Tickets in open, in-progress, pending, or awaiting-vendor status.
- Unit
- Tickets
- Calculation rule
- Count of records that belong to the four open statuses.
- Use
- Evaluate pending workload and aging distribution.
- Limitation
- Represents a snapshot at the demonstration dataset's fixed clock.
MTTR
Average resolution time for resolved or closed tickets.
- Unit
- Minutes or hours
- Calculation rule
- Average resolutionTimeMinutes for tickets with a recorded resolution.
- Use
- Compare resolution efficiency across filters and dimensions.
- Limitation
- Times are generated by the synthetic scenario, not measured in a live operation.
At-risk tickets
Open tickets with resolution deadline consumption between 75% and 100%.
- Unit
- Tickets
- Calculation rule
- Elapsed minutes ÷ resolutionSlaMinutes, including consumption greater than or equal to 75% and below 100%.
- Use
- Demonstrate preventive prioritization before a breach.
- Limitation
- The historical rule uses elapsed minutes; the v2 layer also calculates risk in business hours.
Operational severity
Critical-ticket slice based on P1 and P2 priorities.
- Unit
- Tickets
- Calculation rule
- Count of tickets where priority equals P1 or P2.
- Use
- Highlight tickets with higher potential impact.
- Limitation
- Priority is assigned by the synthetic generator, not by real human triage.
Productivity
Operational profile by technician with open, closed, overdue, SLA, and reassignment measures.
- Unit
- Counts and percentage
- Calculation rule
- Groupings by technician; there is no single productivity score.
- Use
- Analyze workload distribution without reducing performance to one metric.
- Limitation
- Technicians and workload distribution are entirely synthetic.
Recurrence
Ticket with a previous occurrence in the same unit, category, and root cause within 30 days.
- Unit
- % and tickets
- Calculation rule
- Recurring tickets in the window ÷ total filtered tickets.
- Use
- Identify repeated patterns that warrant root-cause investigation.
- Limitation
- The rule depends on the three available dimensions and configured window.
Root cause
Ticket distribution by the consolidated rootCause field.
- Unit
- Tickets
- Calculation rule
- Count grouped by rootCause value.
- Use
- Locate concentrations and guide investigation in the scenario.
- Limitation
- Causes are synthetic categories, not conclusions from a real investigation.
Technical decisions
Typed, deterministic data
- Reason
- Unify mock, seed, and PostgreSQL under a reproducible TypeScript contract.
- Consequence / trade-off
- Contract changes require coordinated updates to generation, persistence, and metrics.
Operational indicator modeling
- Reason
- Centralize SLA, backlog, MTTR, recurrence, and risk in testable functions.
- Consequence / trade-off
- New metrics require aligned documentation and tests.
Separation of data, calculations, and visualizations
- Reason
- Reuse the same rules across APIs, tRPC, and components without coupling them to the interface.
- Consequence / trade-off
- The architecture gains layers that must keep their contracts consistent.
Additional technical decisions
Configurable mock or database source
- Reason
- Keep demonstration mode independent while allowing persistence through Prisma.
- Consequence / trade-off
- The technical source and synthetic nature of records must remain explicit.
Legacy SLA and business-hours SLA
- Reason
- Preserve initial KPIs and provide a Monday-to-Friday, 08:00-to-18:00 view.
- Consequence / trade-off
- The two readings should not be compared without identifying which calendar was used.
Separate analytics views
- Reason
- Separate executive, operational queue, SLA, and root-cause views.
- Consequence / trade-off
- Navigation becomes clearer, but filters and metrics must remain consistent across routes.
Recharts isolated in client components
- Reason
- Provide interactive charts while keeping rules and data access outside the visual layer.
- Consequence / trade-off
- Visualizations add client-side JavaScript and require textual and tabular fallbacks.
Technical evidence
The application, endpoints, and confirmed contracts are presented according to their actual access level.
Public application
Published application
Functional Vercel deployment with a landing page, dashboards, APIs, and a demonstration dataset.
Open evidencePublic endpoint
Health API
Public endpoint for checking service and configured-source status.
Open evidencePublic endpoint
Metrics API
Public endpoint with aggregates from the published app's current database. It changes with use, so its figures do not match the 780-ticket snapshot this case analyses.
Open evidencePrivate source code
Private source code
Verifiable technical evidence is documented in this case study.
Code reference
Typed ticket contract
Fields, enums, and structures used by data, persistence, and views.
Code referencesrc/types/ticket.ts
Implementation references
Code reference
README and execution documentation
Demonstration scope, commands, stack, data, architecture, limitations, and deployment.
Code referenceREADME.md
Code reference
Synthetic data source
Deterministic generator and seed that reproduce the 780 demonstration tickets.
Code referencesrc/data/tickets.ts · prisma/seed.ts
Code reference
Indicator rules
Functions for SLA, backlog, MTTR, groupings, recurrence, and risk.
Code referencesrc/lib/metrics.ts · src/lib/analytics-v2.ts
Code reference
Indicator and chart components
Dashboard composition, KPI cards, Recharts charts, filters, and operational table.
Code referencesrc/components/dashboard/dashboard-client.tsx · kpi-card.tsx · chart-card.tsx
Code reference
KPI documentation
Definitions, formulas, calendars, risk ranges, and metric limitations.
Code referencedocs/kpi-rules.md · docs/analytics-v2.md
Demonstration scenario indicators
- Simulated data
- 29.0%
- Resolution SLA
- Resolution SLA under the historical elapsed-minutes rule.
- Simulated data
- 90
- Open backlog
- Tickets in an open status in the demonstration dataset.
- Simulated data
- 16h 44m
- Average MTTR
- Conversion of the 1,004.4-minute average resolution time.
Indicators calculated from the synthetic dataset of 780 tickets. They do not represent outcomes achieved in a live operation.
Demonstrated capabilities
- Operational indicator modeling.
- Typed data structuring.
- SLA, backlog, and MTTR calculation.
- Risk and root-cause visualization.
- Responsive analytics product development.
- Assumption and limitation documentation.
Limitations and next steps
Limitations
- Exclusively synthetic data and results.
- No active integration with an ITSM platform.
- Demonstration scope without live operational updates; the dashboards require sign-in (Clerk), while the home page and the metrics API are public.
- Optional persistence reproduces the seed; it does not create real data.
Next evolutions
- Integration with an authorized ITSM source.
- Incremental persistence and history.
- Authentication and access control.
- Configurable risk and SLA alerts.
- Expanded automated testing.
- Observability and source-quality monitoring.
Gallery
The images document the product's visual direction. Values shown in the mockups do not replace the audited indicators from the current seed.
Optional technical details
How to run
- Open the published Vercel dashboard.
- Explore the executive KPIs, charts, heatmap, radar, and at-risk ticket table.
- Use the indicators to simulate queue prioritization, SLA analysis, and root-cause investigation.
Next project
Python Automation: Operational Intelligence
Corporate automation center simulating spreadsheet cleaning, file consolidation, report generation, operational logs, and before/after comparisons to demonstrate efficiency gains.
View full case