Claim Management System

This claim management system is a demo application I designed and developed to show how mileage and overtime claims can move through a shared workflow. It uses Laravel and separates the work of staff, supervisors and finance. I present it here as a demonstration of the application and its interface, not as evidence of a live council deployment.

The brief

The problem behind the demo is the handover between the person making a claim, the person checking it and the team arranging payment. A form alone does not explain that whole process. I built the claim management system around the sequence of submission, verification and finance approval. Each role has its own dashboard, so the same workflow can be viewed from the perspective of the person responsible for the next step.

What I built

• A role-based entry screen – The landing page uses persona-based login and an approval-flow graphic. It introduces the separate roles before the user enters a dashboard, which makes the claim management system easier to explore as a complete process.
• A staff dashboard – Staff work with mileage and overtime claims in an interface built for the submitting role. Live calculations show the claim amounts as the user works, rather than leaving all of the arithmetic until review.
• Rate and cap handling – The claim calculations include automatic rate and cap enforcement. I included these rules in the staff workflow so the example demonstrates how calculations and entry screens work together, rather than showing only a finished total.
• A supervisor inbox – Supervisors have a prioritised approval inbox for verification. This separates the checking stage from initial submission and gives the reviewing role a view built around claims that need attention.
• Finance tools – The finance dashboard includes batch payments, CSV exports and monthly spend reports. Those functions demonstrate the work after verification, rather than ending the application at the point where a supervisor reviews a claim.
• An audit trail – Actions have an audit trail across the workflow. The claim management system treats the recorded sequence as part of the application, alongside the dashboards, calculations and approval steps that users see on screen.
• Malay and English screens – A bilingual toggle lets the interface switch between Malay and English. I kept the role-based structure in both languages, so exploring another language does not require learning a different process.
• Responsive interface development – I used Laravel, Tailwind CSS, Alpine.js and MySQL for the application. Layouts cover desktop, tablet and mobile, with keyboard-friendly components and a restrained visual style across the dashboards.

How the claim management system works

The claim management system starts with the user choosing a role. A staff member works with the submission and calculations, a supervisor checks claims through the approval inbox, and finance handles the payment stage and reporting. Viewing these roles separately makes the handovers visible. It also shows why a shared claim process needs more than one screen with every action placed on it.

Within the claim management system demo, the calculation rules and audit trail support that sequence. Finance can work with batches and export data, while the monthly reports provide a view of spend. The language toggle and responsive layouts address how people read and use those screens. This portfolio example describes the demonstrated functions; it does not claim that real payments have been made through the application.

Result

The claim management system demonstrates a complete interface for submitting, checking and handling claims through distinct roles. It gives a prospective client something concrete to discuss: the staff calculation view, the approval inbox, finance reporting and the recorded history. I make no claim here about measured processing-time savings or operational adoption. Those outcomes would need evidence from an actual deployment.

Need an internal application for an approval process?

I can help map who enters information, who checks it and who takes the final action before building the screens. A useful starting point is your current form and the handovers that follow it, including the reports people need at the end. Tell me what you need and I will scope it properly.

Other related projects