POCO Myanmar
An integrated ERP platform unifying field sales and distributor data into one validated system across POCO Myanmar's distribution network.
Stakeholder
Astra-Wealth (POCO authorized distributor)
Role
Product Designer, Team Lead
Services
Stakeholder Consultation, UX Strategy, UI Design, User Testing
Team
3 Developers, 1 Solo Designer
Tools
Figma, Miro, Trello, FigJam
Timeline
4 months, 2026
/ Overview
Astra-Wealth managed hundreds of shops and thousands of devices but have no system to monitor everything in one place.
Operational data was fragmented across Odoo ERP, field sales reporting, and distributor spreadsheets, making coordination impossible across the supply chain.
Three compounding risks:
Unvalidated IMEIs entered inventory freely, making device tracking unreliable.
Stock transfers had no chain of custody, accountability between teams was untraceable.
KPI tracking broke every time staff were reassigned, making performance data unreliable.
/ Target Audience
Every role operated differently, with its own workflows, permissions, and responsibilities that needed to stay clearly separated.
Role
Scope
Responsibility
Performance
Sale Director (Admin)
All regions
Views full system performance. Top of hierarchy.
No KPI
Regional Sale Manager
1 region
Oversees all levels below. One RSM per region.
Monthly KPI
Area Sale Manager
1 division
Oversees trainer and below. Multiple ASMs per division.
Monthly KPI
Trainer
Assigned staff
Performance review only, no sales target.
No KPI
Sale Supervisor
1+ shops
Sells directly and manages promoters. Submits stock-in IMEI per shop.
Monthly KPI
Promoter
1 counter
Sells at assigned counter. Scans and submits received IMEI items.
Monthly KPI
The Outcome
500+
daily active users
6
multi-role interfaces with 1 app
3
data pipelines into one system
/ Research
Three operational gaps were found: fragmented data, no accountability, and broken KPI tracking.
I spent a week with Astra-Wealth's operations leads and regional teams, mapping how work actually flowed. Prior industry experience helped me spot the gaps faster and three systemic failures surfaced immediately.
Finding 1
50% of inconsistent IMEI data are entered into the system with no validation.
Finding 2
Sale performance visibility for 6 different roles are hard to trace across nationwide.
Finding 3
Data are scattered separately: Odoo ERP, field sales input, and distributor Excel uploads.
The workflows of existing structure in a simple way
/ Understanding the Domain
The challenge was designing one system that could support 6 operational roles while bringing together 3 disconnected data pipelines.
The organizational hierarchy became the structural foundation for every permission, screen layout, and data filter in the system.
6 roles organization hierarchy
All 3 separated data pipelines workflows were going parallel, and needed to streamline real-time data control.
Odoo ERP
The primary data for product IMEIs, stock quantities, and shop data are disconnected from day-to-day field operations.
Field Sales Input
Sales data, received product IMEI lists, and sold-out device lists are not properly validated against inventory data.
External Excel Data
Since wholesalers submitted data manually, unauthorized entries and reporting errors could quietly enter the system unnoticed.
The system had to be the bridge between all three data flows, syncing data from Odoo, distributing it to field teams, and validating information coming back from every channel.
Three data flows that need to be synced in a centralized POCO portal
/ Design Approach & Constraints
The system wasn’t just solving UI problems, and it had to support operational reliability across multiple workflows in one integrated system.
Admin portal constraints
Real-Time Data Sync
Stock qty and Shop data between Odoo and Poco admin portal.
Role-based Access
Hierarchical data visibility, Shop management, controlled at the system level.
IMEI Validation
Field sales mobile app and Wholesaler's external data before stock entries could be submitted.
Stock Allocation
Counter-to-counter, Shop-to-Shop, Wholesaler-to-retail for field sales.
KPI Tracking
KPI remains accurate even when staff role or location changes.
Field sales mobile app constraints
Login Authorization
One mobile app for supporting all 6 role-based access authorization.
Hierarchical Sales Tracking
Sales performance tracking from upper to lower levels.
Real-Time Data Sync
Sold qty, on ground received IMEI sent back to Poco admin portal.
I realize that designing for ideal behaviour wasn't realistic.
With over 500 users across different regions, roles, and levels of digital familiarity, the goal was to reduce mistakes through system design, not by relying on users to remember the right process.
It was not "make a nicer dashboard." It was: how do you design a system that pulls from three conflicting data sources, enforces strict validation at every input point, and remains usable by both a corporate director reviewing strategy and managing 6 hierarchies roles?
/ Key Decision: Role-Based Access
I didn't build 6 apps. I designed a 1-to-1 Device-to-Role validation flow.
The Challenge
6 roles
Different workflows
Different permissions
Sync data from same system.
Option I considered
Build 6 different apps
Maintaining six separate experiences would increase development overhead.
Create inconsistencies when staff changed roles.
Turn every update into repeated work.
Role + Device Pairing
Every update is done in one app.
Login credentials will depend on device id.
Need manual approval from admin.
The Solution
Role Id + Device Id Pairing
One device registers one role.
Match the credentials and show the correct interface.
Login requests don't self-approve.
Admin acts as human gate between device and system.
How login authorization flow works on mobile app
Same login screens for all 6 roles to remove frictions and control with "Role ID" and "Device ID".
Login request from mobile app is sent to admin portal for approval.
(After Approval)
In mobile apps, the same interfaces are used, but different data access is determined by which role logs in.
Sale Director
Check all hierarchical roles and sales performance
No KPI
Regional Sale Manager
KPI with region access
Check sales of ASM, Trainers, Sale Supervisors, and Promoters under him.
Sale Supervisor
Have KPI
Manage own sales (Non-PG sales) and team sales (PG sales) under him
Promoter
Have KPI
Manage own sales to end customers and shop counter
Outcomes
Unauthorized access has been reduced to 0% from launch.
Any role update deploys once, not six times.
/ Key Decision: Data Integrity
Getting data into the system was only half the problem. The harder question was: "how to keep bad data out."
/ IMEI Validation
Different IMEI flows for promoters and supervisors are driven by shop structure, not permissions.
Multiple promoters share one shop. If all of them could check a shared IMEI list, they'd check the same items, creating duplicate submissions and wrong inventory data.
Supervisors get the checklist because they work solo across multiple shops and no duplication risk exists there.
Promoter: Scan Only
Scans IMEI for their assigned counter. No checklist feature.
Sale Supervisor: Scan & Checklist
Same IMEI scan flow, but with an added IMEI checklist.
Outcomes
Zero duplicate IMEI entries are recorded post-launch across all 500 users.
/ Handling stock transfer
There are 3 types of stock transfers, and every transfer has to stay traceable.
The unique IMEI number is the critical anchor for tracking stock, managing data, and verifying transfers across the entire application ecosystem.
Counter to Counter
Items are transferred between counters under the same shop.
Shop to Shop
Items are transferred between across different locations.
Wholesaler to Retail
Wholesaler-to-retail is the highest risk channel, relying entirely on manual Excel uploads.
So, how to keep every stock transfer accountable? Without tracing every IMEI, stock could change hands with no record of where it came from or where it went.
Stock enters a counter in two ways: promoters scan allocated stock on the ground, and admin transfers it between counters. The IMEI list is recorded regardless of any transfer.
Counter Stock allocation from promoter IMEI submission
Counters receive allocated stock. Promoters scan each IMEI on receipt. So, only validated items enter the system.
Every scanned IMEI syncs back to the portal.
Stock status and sold date tied to every IMEI, no cross-referencing.
IMEI tracking drives full stock visibility across the system.
Next is how to prevent unauthorized wholesaler IMEIs from silently entering the system?
/ Preventing bad data through Excel uploads
The Excel channel is highest-risk because it operates outside real-time input controls.
Instead of fixing bad data later, I designed a three-step validation process before any sold-out IMEI information could enter the system.
Step 1: Review and verify before submission
Once Excel is uploaded, all sold item rows are validated against the wholesaler's original stock of IMEI lists.
Step 2: IMEI validation against the wholesaler's registered Odoo stock
Once Excel is uploaded, all sold item rows are validated against the wholesaler's original stock of IMEI lists.
(Valid case)
Successful IMEI validations with wholesalers' stock with Odoo ERP are transferred to created retail shops.
(Invalid case)
Invalid IMEIs are logged out with an error message line for Excel.
Step 3: Adjust inventory consistency
After IMEI validation is done, the system automatically deducts the sold quantity from the wholesaler’s stock balance. At the same time, the deducted quantities are added to the received retailer shop.
Here is validating and transferring flow:
/ Key Decision: Shop & Counter Assignment
Not all shops operate the same way, and the shop structure has become more than just location management.
Shop and assignment structure
Shops with counters are assigned to promoters.
Shops without counters are assigned to sale supervisors.
/ Iterative design approach for kpi
Uncoupled KPI settings from the actual shop and counter assignments.
Originally, KPI was set when assigning a promoter to a shop counter. This seemed true until testing revealed: when a promoter moves to a different counter, the KPI breaks and it stays tied to the old counter.
Setting KPI seems logically correct.
Iterative Approach
I decided to move KPI configuration entirely into the role management section. KPI is now attached to a person, not a location. Admin can check any role's KPI directly without hunting through shop assignments.
Outcomes
KPI data stays accurate through any reassignment.
Accessing KPI steps has reduced to just one click.
/ Iterative design approach for stock analysis
Why decide to merge stock analysis instead of three separated views?
Initial design had three separate menu tabs: Shop Level, Counter Level, and IMEI Tracking. During testing, this created an unexpected problem: shops with many counters flooded the interface with repetitive rows. Admins couldn't scan across all shops quickly.
3 separated screens slow down admin processing with long scrolling.
Shop Level
Counter Level
IMEI Tracking
Iterative Approach
Merged shop and counter data into a single hierarchical view with expandable rows. IMEI tracking became accessible inline.
Shop Level
Counter Level
IMEI Tracking
Outcomes
Second time testing significantly improve admin processing speed with inline stock analysis.
3 long scroll for 3 different tab has reduced to 2 inline steps in one tab.
/ Outcome
The system has been shipped within timeline, and now running live. But new edge cases and workflow improvements continue to surface through real-world usage.
Managing Login Friction Across Device Changes
Since the system is designed a one-device-per-user model, users occasionally faced login issues when using UUID for approval.
UUID wasn't unique enough across devices, breaking the one-device-per-user model. We changed to Device ID, and it solved the incidents.
/ Takeaways
What I've learned
Logic comes before screens
The KPI model became one of the biggest lessons in the project. Since then, I’ve treated workflow logic and edge cases as part of design, not something that comes afterward.
Error states build trust
The IMEI validation flow taught me that error handling is not a supporting feature, it is part of the product experience itself.
Constraints shape the experience
Many of the most important design decisions came from constraints rather than visual decisions. Instead of treating edge cases as exceptions, I learned to design around them early.
See Next Project
SUPPLINK
Reducing ordering friction through inventory visibility and supplier-retailer coordination
UX/UI . uT . E-commerce . supply chain
YUMMIESTREETS
Easing barriers for backpackers to enjoy authentic street food in Thailand
UX . Research . UT . Food Ordering