🎫 ABC Tech — ITSM Incident Management Analytics

End-to-end IT Service Management analytics platform — from raw incident data to deployed ML models

An end-to-end data science project built on confidential client incident data, demonstrating the complete ML lifecycle — from data engineering through production-style deployment.

---

📖 Table of Contents

• About the Project
• Problem Statements & Results
• Screenshots
• Tech Stack
• Repository Structure
• Getting Started
• Methodology Highlights
• Author

---

📌 About the Project

ABC Tech is an IT organization that logs, tracks, and resolves incident tickets through an ITSM (IT Service Management) platform. This project analyzes historical incident data to solve four independent, business-driven machine learning problems, each treated as its own mini-pipeline — with its own leakage-safe feature set, model benchmarking, and evaluation strategy.

Note: This project was built on a real client dataset under an NDA. Dataset internals, schema, and raw data are intentionally not published in this repository — only the methodology, code, and results are shared.

#	Problem Statement	Type	Status
PS1	Predict high-priority tickets at open time	Binary classification (imbalanced)	✅ Deployed
PS2	Forecast daily incident ticket volume	Time-series forecasting	✅ Deployed
PS3	Auto-tag ticket priority & department	Multi-class classification	⚠️ Feasibility analysis
PS4	Predict RFC (Request for Change) risk	Binary classification (severely imbalanced)	✅ Deployed

---

🔍 Problem Statements & Results

PS1 — High-Priority Ticket Prediction

Flags high-priority tickets automatically at open time, using only fields known the moment a ticket is filed — strictly excluding anything only known after the ticket is worked, to avoid data leakage.

• Benchmarked Logistic Regression, Random Forest, XGBoost (with class-weighting, threshold tuning, SMOTE), and CatBoost, on a severely imbalanced target (~1.5% positive class)
• Final model: CatBoost @ threshold 0.55 — F1 0.5460 · ROC-AUC 0.9414 · PR-AUC 0.4663 (Alternative: XGBoost @ threshold 0.897 trades recall for precision — F1 0.5714)
• Top drivers: Configuration Item category/subcategory and work-breakdown structure fields account for ~60% of feature importance

PS2 — Daily Incident Volume Forecasting

Forecasts incident ticket volume per day to support staffing and shift planning. Modeled as a univariate time series with a chronological train/test split.

• Benchmarked Naive baseline, ARIMA, SARIMAX, Holt-Winters, and Prophet
• ACF/PACF analysis confirmed strong weekly seasonality
• Final model: SARIMAX(5,1,4)(0,0,1,7) — MAE 31.04 · RMSE 39.71 tickets/day (best absolute error of all models tested)

PS3 — Priority & Department Auto-Tagging

Scoped to auto-tag incoming tickets with priority and support department. A structured feasibility analysis determined the department-tagging component was not achievable with the available data, and this was documented transparently as a feasibility study rather than forcing a low-quality model.

PS4 — RFC (Request for Change) Prediction

Predicts whether an incident is likely to trigger a Request for Change, framed as a binary classification problem on a severely imbalanced target (~1.2% positive class).

• Benchmarked XGBoost, LightGBM, Random Forest, Logistic Regression, SMOTE-balanced models, and CatBoost
• Key methodological finding: switching from a random train/test split to a chronological split (mimicking real production deployment) nearly doubled model performance
• Final model: Optuna-tuned CatBoost (chronological split) — Precision 0.2700 · Recall 0.6574 · F1 0.3827 · ROC-AUC 0.8185 · PR-AUC 0.1856

---

🖼️ Screenshots

Landing Page	Priority Prediction

RFC Prediction	Ticket Forecasting

---

⚙️ Tech Stack

Data & ML: Python, pandas, NumPy, scikit-learn, XGBoost, LightGBM, CatBoost, Optuna, imbalanced-learn Time Series: statsmodels (ARIMA/SARIMAX), Prophet Backend: FastAPI, Pydantic, Uvicorn Frontend: Streamlit, Plotly Tooling: Jupyter Notebook, Git

---

🏗️ Repository Structure

ABC-Tech-ITSM/
├── assets/
│   ├── landing_page.png
│   ├── priority_prediction.png
│   ├── rfc_prediction.png
│   └── ticket_forecasting.png
├── Models/
│   ├── priority_pred.joblib         # PS1 — CatBoost, threshold 0.55
│   ├── rfc_pred.cbm                 # PS4 — CatBoost (native format), threshold 0.54
│   └── tickets_forecasting.joblib   # PS2 — SARIMAX(5,1,4)(0,0,1,7)
├── ABC Tech ITSM.ipynb              # Full analysis notebook (EDA + PS1–PS4)
├── ITSM_ABC_Tech_Project_Report.pdf # Formal written project report
├── app.py                           # FastAPI backend serving all deployed models
├── streamlit_app.py                 # Streamlit dashboard (calls the FastAPI backend)
└── requirements.txt                 # Python dependencies

---

🚀 Getting Started

1. Clone & install dependencies

git clone https://github.com/ENGABHAY/ABC-Tech-ITSM.git
cd ABC-Tech-ITSM
pip install -r requirements.txt

2. Start the FastAPI backend

uvicorn app:app --host 0.0.0.0 --port 8000 --reload

Available endpoints:

• POST /predict/priority — PS1 high-priority prediction
• POST /predict/rfc — PS4 RFC risk prediction
• GET /forecast — PS2 incident volume forecast
• GET /docs — interactive Swagger UI

3. Launch the Streamlit dashboard

streamlit run streamlit_app.py

By default it targets http://localhost:8000 — update the API base URL in the sidebar if the backend is deployed elsewhere.

---

🧠 Methodology Highlights

• Strict leakage policy: only fields known at ticket-open time are used as model features across PS1 and PS4 — never post-resolution fields.
• Imbalance-aware evaluation: PR-AUC, per-class precision/recall/F1, and threshold tuning were prioritized over plain accuracy on both severely imbalanced classification tasks.
• Chronological validation for production realism: PS4 explicitly compares random vs. chronological splits and demonstrates why the latter better reflects real-world deployment.
• Honest model comparison: every problem statement benchmarks multiple algorithms and transparently reports trade-offs between competing "best" models rather than optimizing a single number.
• Transparent scoping: where a problem statement wasn't feasible with the available data (PS3), this was documented as a formal feasibility analysis rather than forced or fabricated.

---

👤 Author

Abhay Kadam Data Science & Machine Learning | GitHub · LinkedIn

---

_{Academic capstone project — built on a confidential client dataset for educational purposes.}