Queue Management System for NDS V3
Queue Management System for NDS V3
Queue Management System for NDS V3
The Queue Management System (QMS) enables Frontliners to manage and serve customers waiting at the branch from selecting the next customer to be served and managing queue delays according to business rules, to accurately recording service start and completion times.
The Queue Management System (QMS) enables Frontliners to manage and serve customers waiting at the branch from selecting the next customer to be served and managing queue delays according to business rules, to accurately recording service start and completion times.
Why we built NDS V3?
Why we built NDS V3?
Why we built NDS V3?
The previous version of NDS had been in use for an extended period but still presented several operational and business gaps:
• Transactions could proceed without the customer being physically present, creating potential fraud risks.
• Service level data was unreliable because transaction start and stop times could be manipulated.
• Branch queue management relied heavily on QMS availability.
• Cross selling opportunities were not consistently surfaced, and customer product context was not always visible during service.
• New NDS features were not communicated effectively across business units.
NDS v3 was designed to address these gaps while establishing a stronger foundation for future operations, introducing BVP (Biometric Verification Point), ensuring customer data security through BVP validation, minimizing fraud, optimizing queue flow without dependency on branch QMS, improving SLA accuracy, enabling cross selling optimization to increase sales opportunities, increasing Frontliner awareness of customer product holdings, surfacing new features on the homepage, and strengthening BRI rebranding across the interface.
The previous version of NDS had been in use for an extended period but still presented several operational and business gaps:
• Transactions could proceed without the customer being physically present, creating potential fraud risks.
• Service level data was unreliable because transaction start and stop times could be manipulated.
• Branch queue management relied heavily on QMS availability.
• Cross selling opportunities were not consistently surfaced, and customer product context was not always visible during service.
• New NDS features were not communicated effectively across business units.
NDS v3 was designed to address these gaps while establishing a stronger foundation for future operations, introducing BVP (Biometric Verification Point), ensuring customer data security through BVP validation, minimizing fraud, optimizing queue flow without dependency on branch QMS, improving SLA accuracy, enabling cross selling optimization to increase sales opportunities, increasing Frontliner awareness of customer product holdings, surfacing new features on the homepage, and strengthening BRI rebranding across the interface.
Problem insights?
Problem insights?
Problem insights?
How might we design a queue calling flow that ensures every transaction is associated with a verified customer, accurately captures service duration for SLA measurement, and remains operational when branch QMS is unavailable without adding unnecessary complexity to the Frontliner's workflow?
How might we design a queue calling flow that ensures every transaction is associated with a verified customer, accurately captures service duration for SLA measurement, and remains operational when branch QMS is unavailable without adding unnecessary complexity to the Frontliner's workflow?
Key design challenges
Key design challenges
Key design challenges
Two different mechanisms
Two different mechanisms
QMS with BVP and QMS without BVP needed to feel like one consistent flow rather than two separate features.
QMS with BVP and QMS without BVP needed to feel like one consistent flow rather than two separate features.
Queue postponement rules
Queue postponement rules
Needed to be clearly communicated in the UI to prevent customers from being postponed incorrectly.
Needed to be clearly communicated in the UI to prevent customers from being postponed incorrectly.
Start and Complete actions
Start and Complete actions
Needed to be mandatory while still feeling like natural steps within the workflow.
Needed to be mandatory while still feeling like natural steps within the workflow.
Approach
Approach
Approach
Mapping the existing flow & business rules
Mapping the existing flow & business rules
Before moving into interface design, I mapped the complete conditional logic with the product team, including when QMS was available or unavailable, when BVP verification was required, and the applicable queue postponement rules.
This was important because the flow contained multiple conditional scenarios. Any gap in the initial logic mapping could affect the entire set of screens and interactions downstream.
Before moving into interface design, I mapped the complete conditional logic with the product team, including when QMS was available or unavailable, when BVP verification was required, and the applicable queue postponement rules.
This was important because the flow contained multiple conditional scenarios. Any gap in the initial logic mapping could affect the entire set of screens and interactions downstream.
Designing multiple components
Designing multiple components
Several components within this flow like a cards, status badges, primary action buttons, and BVP notification banners had the potential to be reused across other NDS v3 flows. I documented these patterns within the NDS v3 Design System, including:
• Component naming.
• Interaction states such as default, disabled, and loading.
• Usage guidelines.
• Consistency requirements across related flows.
This created reusable patterns that could be consistently implemented by other designers and developers across NDS v3.
Several components within this flow like a cards, status badges, primary action buttons, and BVP notification banners had the potential to be reused across other NDS v3 flows. I documented these patterns within the NDS v3 Design System, including:
• Component naming.
• Interaction states such as default, disabled, and loading.
• Usage guidelines.
• Consistency requirements across related flows.
This created reusable patterns that could be consistently implemented by other designers and developers across NDS v3.
Designing the core actions: start and complete
Designing the core actions: start and complete
• The Start button / Panggil Antrian button is positioned as the primary action immediately after the Frontliner selects a customer, ensuring service time is recorded from the beginning of the interaction.
• The Complete action / Akhiri Layanan button is designed to be explicit and cannot be unknowingly skipped, helping ensure it is used to end the customer service session and complete the existing queue within the Opsi Layanan menu.
• Queue states (priotitas, tunda, transfer, selesai) are clearly displayed so Frontliners and supervisors can monitor service progress in real time.
• The Start button / Panggil Antrian button is positioned as the primary action immediately after the Frontliner selects a customer, ensuring service time is recorded from the beginning of the interaction.
• The Complete action / Akhiri Layanan button is designed to be explicit and cannot be unknowingly skipped, helping ensure it is used to end the customer service session and complete the existing queue within the Opsi Layanan menu.
• Queue states (priotitas, tunda, transfer, selesai) are clearly displayed so Frontliners and supervisors can monitor service progress in real time.
Prototyping and validation
Prototyping and validation
I built an interactive prototype in Figma to simulate the key scenarios, including QMS with BVP and QMS without BVP. The prototype was then tested with stakeholders to validate the flow logic and interaction patterns before development.
I built an interactive prototype in Figma to simulate the key scenarios, including QMS with BVP and QMS without BVP. The prototype was then tested with stakeholders to validate the flow logic and interaction patterns before development.
Project impact
Project impact
Project impact
• Reduced risk of fictitious transactions and fraud, the introduction of BVP adds a customer presence and consent validation layer before the transaction can proceed. This helps reduce the risk of transactions being initiated without the customer's physical presence.
• The frontliner workflow stays efficient, although BVP introduces an additional verification layer, it is integrated directly into the customer calling flow rather than being treated as a separate process.
• Components were documented within the NDS design system.
• Reduced risk of fictitious transactions and fraud, the introduction of BVP adds a customer presence and consent validation layer before the transaction can proceed. This helps reduce the risk of transactions being initiated without the customer's physical presence.
• The frontliner workflow stays efficient, although BVP introduces an additional verification layer, it is integrated directly into the customer calling flow rather than being treated as a separate process.
• Components were documented within the NDS design system.
