BPP: Raise a Query

OVERVIEW

As part of the wider BPP mobile app experience, I led the end-to-end design of the “Raise a Query” experience, aimed at helping students quickly access support for issues related to finance, accounts, and general administration.

The goal was to reduce friction in the support journey by encouraging self-service first, while still allowing students to submit a query when needed.

THE PROBLEM

Students often struggled to:

• Know where to go for support

• Find the correct contact point for different issues

• Access relevant help content quickly

• Track existing support requests

• Locate the right information in the Help Centre

At the same time, support teams were receiving large volumes of repetitive queries that could potentially be resolved through clearer guidance or self-service support.

RESEARCH & INSIGHTS

Research and support analysis revealed several recurring behaviours:

• Students raised tickets before attempting self‑service because they lacked confidence in selecting the right category.

• A large portion of queries were repetitive and already answered in help centre content.

• Duplicate tickets were common, increasing operational load and slowing response times.

These insights shaped a more guided, intelligent support flow that encouraged self‑service while still enabling escalation.

KEY FEATURES

Guidance & Personalisation

• Course and programme selection

• Contextual help centre nudges

• Confirmation prompts after viewing articles

Prevention & Efficiency

• Duplicate ticket detection

• Clear categorisation and sub‑categories

• Reassurance and progress indicators

Escalation Support

• File uploads

• Success and error states

• Clear escalation path if self‑service fails

CONTINUOUS INSIGHT & ITERATION

The query flow also became a valuable source of behavioural insight. By regularly monitoring the most common support requests submitted through the form, we were able to identify recurring student pain points and areas of confusion across the wider BPP experience.

This data helped inform:

• future product priorities

• improvements to help centre content

• chatbot training opportunities

• UX improvements across related journeys

• operational focus areas for support teams

The query data created an ongoing feedback loop, allowing us to continuously refine the experience based on real student behaviours and needs.

TRADE-OFFS & CONSTRAINTS

• We needed to reduce support load without blocking students from getting help.

• The experience had to work within existing support tooling and ticketing systems.

• We intentionally added light friction to discourage unnecessary escalation.

• We prioritised clarity and guidance over speed to reduce misrouted tickets.

THE SOLUTION

I designed a multi-step support flow that progressively guided students from category selection through to submission — with contextual help centre nudges, duplicate detection, and confirmation prompts built into the journey. The experience intentionally added light friction to encourage self-service before escalation.

KEY LEARNINGS & Impact

By making the query journey clearer and easier to use, we unintentionally increased ticket volume. Students who previously gave up were now confident enough to submit — creating more operational load, not less.

The insight: in support journeys, removing friction entirely can work against you.

This led us to pivot to a chatbot-first model, shifting the support journey to chatbot first, then self-service guidance, then escalation to "Raise a Query" only when needed. A/B testing confirmed the approach — most queries were resolved by the bot before escalation, allowing us to phase out the form entirely.