SLA Management System

Inspiration

The idea came from watching how often service teams miss SLA deadlines not because they're incapable, but because they're blind. Commitments live in scattered spreadsheets, emails, and sticky notes, and by the time someone notices a breach, the damage — a penalty, an angry client, a broken trust — is already done. We wanted to build something that flips this: catch the problem before it happens, not report on it after.

What We Built

We built a lightweight SLA Management System using Python for the backend logic, Streamlit for a fast, interactive dashboard, and a relational database to persist contracts, tickets, and time-tracking data.

Core features:

Automated tracking of response and resolution timers against SLA thresholds
Real-time dashboards showing SLA health across clients and contracts
Threshold-based alerts that fire before a breach, calculated as: Time Remaining = SLA Deadline − Current Timestamp. If Time Remaining is less than the Alert Threshold, the system flags the ticket for escalation.
Auto-generated compliance reports to replace hours of manual spreadsheet work

How We Built It

Data layer — Designed a schema to store contracts, SLA rules, tickets, and timestamps.
Logic layer — Python scripts calculate SLA status in real time and trigger alerts when tickets cross risk thresholds.
Interface layer — Streamlit powered the dashboard, letting us iterate on visuals quickly without a heavy frontend build.
Testing — Simulated ticket streams with varying priority levels to validate that alerts fired at the right time.

Challenges We Faced

Real-time-ish updates in Streamlit: Streamlit isn't natively built for live, continuously updating dashboards, so we had to work around its rerun model to simulate near-real-time alerts.
SLA rule complexity: Different contracts had different rules (business hours only, tiered priorities, grace periods), which made the deadline calculation logic more complex than expected.
Data modeling under time pressure: Getting the database schema right early mattered a lot — we had to refactor once we realized escalation paths needed their own table.

What We Learned

How much complexity hides inside something that sounds simple, like "track a deadline."
Streamlit is excellent for rapid prototyping but requires careful state management for anything approaching real-time behavior.
Designing for proactive alerts (before breach) instead of reactive reporting (after breach) completely changes how you structure your data and logic.