A Flask and SQLite helpdesk workflow prototype designed for ICT support, retail technology support, and repair-oriented service environments.
This project demonstrates ticket intake, staff and manager workflows, assignment, status tracking, proof submission, manager review, rejection and resubmission, closure decisions, and audit history.
It was built as part of my ICT support portfolio to show practical understanding of support records, escalation, follow-up visibility, handover, documentation, and workflow improvement.
This is a local learning prototype, not a production ITSM system. All data used in this project is fake demo data.
In ICT support and retail technology environments, resolving an issue is only one part of good service delivery.
A useful workflow also needs clear intake, accurate status tracking, service notes, follow-up records, manager review, escalation history, and enough context for another person to understand what happened.
This project was created to practise those support behaviours through a simple ticket workflow.
- Create tickets with title, description, category, priority, visibility, and assigned staff
- Track ticket status across pending, assigned, in progress, submitted, approved, rejected, closed, and voided states
- Edit ticket details and assignment as a manager
- Use fake demo ticket data for safe local testing
- View assigned tickets
- Start assigned work
- Submit proof notes or completion evidence
- View rejected tickets requiring follow-up
- Resubmit corrected work after manager feedback
- Assign or edit ticket ownership
- Review submitted work
- Approve, reject, close, or void tickets
- Add manager notes and rejection comments
- Return work with clear correction reasons
- Maintain audit history for ticket actions
- Show dashboard-style ticket summaries
- Track workload and follow-up needs
- Keep records clear enough for handover and later review
The system follows a basic support lifecycle:
- Create a support request or operational task
- Record the issue, category, priority, and assigned staff member
- Track the ticket as work moves forward
- Staff starts work and submits proof notes
- Manager reviews the submitted work
- Manager approves, rejects, closes, or requests follow-up
- Staff corrects and resubmits if required
- The system keeps an audit history of ticket actions
The dashboard gives staff and managers a quick view of ticket volume, status counts, assigned work, and demo login access.
Tickets can be searched, filtered, sorted, and reviewed from a single operational list.
Staff can report an issue with type, title, description, visibility, and proof type.
Managers can create tasks, assign staff, set visibility, and choose proof requirements.
Managers can open ticket actions such as viewing details, assigning staff, editing tickets, approving proof, returning work for follow-up, or voiding a ticket.
More workflow details
The ticket detail view shows the issue description, assignment, reporter information, visibility, proof reference, staff notes, manager notes, and timestamps.
Each ticket keeps an activity record so the workflow can be reviewed later for handover, follow-up, and accountability.
The manager follow-up view highlights rejected or returned work that may require correction, resubmission, or coaching.
A staff member is assigned a device check, repair follow-up, customer issue, or store technology task.
They complete the work and submit supporting notes. A manager reviews the submission and either approves it or returns it with feedback. If returned, the staff member corrects the issue and resubmits.
The record can later support handover, repeated issue review, SOP improvement, and staff training.
- Python
- Flask
- SQLite
- HTML templates
- Vanilla JavaScript
- Local fake demo data
pip install -r requirements.txt
python app.pyThen open:
http://127.0.0.1:5002/
Update this section with the actual safe demo accounts before publishing.
| Role | Username | Password |
|---|---|---|
| Manager | manager | 1234 |
| Staff | staffa | 1234 |
| Staff | staffb | 1234 |
This project only uses fake or recreated demo information.
It must not include:
- Real customer names
- Real staff names
- Real business names
- Real workplace screenshots
- Real SOP documents
- Real payment, warranty, refund, or repair records
- Real phone numbers, emails, addresses, serial numbers, IMEI numbers, or internal records
This project demonstrates practical ICT support thinking, including:
- Clear ticket intake and status tracking
- Role-based staff and manager workflows
- Service notes and proof submission
- Manager review and correction logic
- Rejection, follow-up, and resubmission handling
- Audit history and handover visibility
- Privacy-aware use of fake demo data
- Workflow improvement thinking for SOPs, onboarding, and training
Planned improvements:
- Improve manager assignment and edit flows
- Strengthen ticket status transitions
- Add focused tests for key workflow actions
- Add a guided demo route with fake users and fake tickets
- Add structured SOP guidance cards using fake demo content
- Improve screenshots and demo presentation
This is an active learning prototype intended for local demonstration and portfolio discussion.
The current focus is to keep the workflow stable, use safe fake demo data, and present the project clearly as an ICT support and retail operations workflow example.