Thinking Process & Root Cause Identification

We talked to the people actually using the system. We asked them what they were trying to do, what was stopping them, and what would make their work easier.

It checked too many bus routes before giving out seats, counted available spots in confusing ways, and no one knew when seats should be saved or freed up. Because it was built in Salesforce with lots of custom code, the system was hard to fix and maintain, especially since the logic was spread all over the place with poor documentation.

All this meant families couldn’t book travel, and staff had to spend hours fixing mistakes and answering complaint calls. This also started impacting the credibility of schools.

Digging Into the Root Causes

We used a simple but powerful method of asking ‘why’ and ‘what’ at every level to help uncover the true source of each problem.

– Why wasn’t seat booking working? Because the system for releasing seats was broken.

– Why was the seat release logic broken? Because not all business rules were captured.

– Why weren’t the business rules captured? Because the team had been told to rebuild the system by mimicking an outdated legacy application, without understanding how people actually used it.

This same pattern showed up everywhere. The project was built on guesses, not on what people actually needed.

Getting Everyone On The Same Page

We brought all the key players together, including the department staff, schools, transport operators, and developers, and drew out the entire journey, from when a family starts an application to when a student gets on the bus.

This exercise revealed even more gaps:

• Conflicting logic and inconsistent data due to validation rules
• The application process was unnecessarily long.
• Route logic triggered multiple times due to which seat was not released, and seat allocation was incorrect
• Eligibility rules were overly complicated.
• Communication between teams and stakeholders was inconsistent.
• Feedback loops were missing, so no one knew when or how issues were being fixed.

Once everything was visible, the problems finally made sense.

Designing Practical, Testable Solutions

With everyone agreeing on what mattered most, we focused on the biggest issues that affected users. We simplified things step by step.

Simpler Route Checking: The system now only checks the two best routes instead of five, which is faster and causes fewer errors.

Clearer Seat Booking: One straightforward process now handles all seat bookings, making it predictable and easier to maintain.

Instant Updates: Instead of updating overnight, the system now updates immediately so people always see current information.

Clear Triggers: Specific actions now control when seats are booked or released, removing confusion.

Flexible Capacity: The system can now adjust how many seats are available based on actual use, not rigid pre-set limits.

We built, tested, and improved each fix with feedback from users before moving to the next one.

Building Trust and Momentum

We knew rebuilding the system wasn’t enough, so we had to rebuild trust, and we did that by:

• Holding weekly check-ins with all stakeholders to keep everyone informed.
• Maintaining a live dashboard to help make progress visible at all times.
• Running regular showcase sessions that let stakeholders see improvements firsthand and offer feedback immediately.

We also looked after the team. We balanced workloads and gave people “no meeting” days so they could focus on their work.

Outcomes

Within three to four months, the turnaround was undeniable.

• The high-impact features were delivered incrementally to a small subset of schools before wider rollouts.
• Seat allocation processing time dropped by 40%.
• Manual interventions by administrators fell by 60%.
• Seat utilisation improved by 95%.
• Stakeholder satisfaction climbed from 2 out of 10 to 7 out of 10.
• Retrospectives pointed towards positive team morale, with burnout rates down by 60%.

The approach we took didn’t just fix a broken system; it became a model for how user experience and research could be embedded as part of the delivery model for other government projects.

What We Learned

This experience taught us some important lessons:

• Always question assumptions and understand what people are trying to accomplish
• Simple always beats complicated
• Delivering value quickly is the best way to build trust
• Taking care of your team is essential for long-term success