[Python] How can I forecast ticket resolution or queining time using historical ticket data in...

I want to build a model that forecasts ticket resolution time for a data science software support tickets . I’ve calculated queuing time and resolution time from ticket data using pandas, and now I want to build a model to predict future resolution times I’m not sure what type of model or preprocessing steps I should use to get reliable time estimates.

df[['Issue Type', 'Priority', 'Queuing Time (hrs)', 'Resolution Time (hrs)']]

**I want to know which model is best suited to predict resolution times and how to evaluate its accuracy.

Full Dataset Structure: Software/Data Science Tickets

General Overview

• Ticket ID: Ranges from TICKET001 to TICKET100.

Date and Time Fields

• 
  Creation Date/Time:
  
  • Randomly assigned between January 3, 2022 and June 26, 2025.
  • Excludes holidays (e.g., public holidays).
  • Timestamps are between 08:00 AM and 06:00 PM (working hours).
• 
  Resolution Date/Time (for Resolved/Closed tickets only):
  
  • Set 1–14 days after the Creation Date/Time.
  • Also excludes holidays.

Ticket Description

• Issue Description: 100 unique, descriptive software/data science-related issues.
  • Categories include: Bugs, Feature Requests, Tasks, Improvements.
  • Examples:
    • "Memory leak in ML model training process"
    • "Feature request: Add anomaly detection to pipeline"
    • "Slow API response for data query endpoint"
    • "Task: Refactor ETL script for scalability"
    • "Improve model accuracy for sentiment analysis"

Ticket Properties

• 
  Priority:
  
  • Categories: Low, Medium, High, Critical.
  • Urgent issues (e.g., production bugs) marked as High/Critical.
• 
  Status:
  
  • Reflects ticket lifecycle: Open, In Progress, Resolved, Closed.
  • Distribution balanced to simulate realistic queue progression.
• 
  Ticket Type:
  
  • Types include: Bug, Feature Request, Task, Improvement.
  • Bug is the most frequent type.
• 
  Severity:
  
  • Aligned with Priority (e.g., Critical → Blocker).
• 
  Assignee:
  
  • Names from a defined pool:
    • john_doe, mary_smith, dev_team_alpha, dev_team_beta, alice_jones, bob_lee
• 
  Ticket Solved By:
  
  • Matches Assignee for Resolved/Closed tickets.
• 
  Ticket Issued Person / Requester:
  
  • Selected from pool:
    • user_1, user_2, client_x, client_y, client_z
  • May overlap with Ticket Issued Person.

Classification Fields

• 
  Project/Module:
  
  • Assigned to one of:
    • Data_Pipeline, ML_Model, Analytics_Dashboard, Database, API
• 
  Queue Name:
  
  • Assigned based on issue type:
    • Backend_Dev_Queue, ML_Dev_Queue, UI_Dev_Queue
• 
  Environment:
  
  • Weighted toward Production for realism.
  • Other options: Staging, Testing, Development
• 
  Arrival Source:
  
  • Sources include: User-Reported, System Alert, QA, Internal
  • User-Reported is most common.

Additional Fields

• 
  Effort Estimate:
  
  • Range: 2–16 hours
  • Reflects task complexity and scope.
• 
  Commit Comments (only for Resolved/Closed tickets):
  
  • Examples:
    • "Updated model parameters"
    • "Added new endpoint"
    • "Refactored data ingestion pipeline"

What I tried: I have a dataset of 100+ support tickets with fields like issue type, priority, queuing time, resolution time, and total time. I loaded this into a pandas DataFrame and explored the data using groupby and plotting. Then, I tried using a Linear Regression model to predict resolution time, but the results were not very accurate.

What I expected:

I expected the model to forecast resolution time more accurately based on past ticket patterns. I was also hoping to understand which features (e.g., issue type, priority) have the most impact on resolution time.

What happened instead:

The model gave very high error (MAE > 10 hours), and I’m not sure if I’m using the right approach or if I need to preprocess or engineer better features. I’d like help improving the model or knowing if a different algorithm (e.g., XGBoost, RandomForest, or time series models) is better suited.

Continue reading...