

Transporter Assingnment Workflows for NETMOS, India.
Floww Delivery APIs. X NERCMOS
Logistics / Transport Infrastructure / GovTech
Product Design / UX Design
📈
5-year MOU signed between Floww and NER Government for the NETMOS rollout
🚀
Design direction validated for transporter assignment workflows
📈
Transporter onboarding initiated as the part of the first rollout.
🧭 What is NETMOS ?
NETMOS is a government-backed Transport Management System (TMS) that tracks and manages how goods move across North-East India through three apps and a central MIS dashboard.
It operates through four connected applications:
Rush (Field/Operations App): Individuals, Govt, farmers & businesses create orders (often with subsidised or supported logistics).
Pragati Transporter (Transporter-facing app) : Accept orders, plan routes, assign drivers, and manage execution.
Pragati Driver (Driver-facing app) : Receive assignments, update status, and complete deliveries.
MIS Monitoring Dashboard (Administrative dashboard.) : Authorities track movement patterns, performance, and bottlenecks.
👀 Zooming Into the
Transporter Experience
While NETMOS consists of four applications, this case study focuses specifically on Pragati — the transporter-facing experience as Transporters sit at the center of execution. They coordinate between orders (Rush) and drivers (Driver app).
Pragati is the transporter’s primary workspace within the NETMOS ecosystem. Transporters use Pragati to manage their business, view incoming orders, accept or reject bids, and plan how deliveries will be executed.
For this model, we zoom in on how transporters assign drivers and vehicles to orders, and how these assignments are structured across a journey.
🔄 How Transporters Operate & Assign — and What Digitising Might Look Like.
Transporters coordinate logistics largely through experience, calls, and relationships. A typical day looks like:
Multiple orders handled in parallel, with trips planned in parts based on availability
Frequent changes due to weather, road conditions, or vehicle availability (especially in the NER)
Decisions made based on who is available right now, not perfect planning
Through ground research, conversations across the ecosystem, and documentation review, we realised that logistics is inherently physical, unpredictable, and messy — especially in the North-East — and deeply relationship-driven, making people cautious about adopting new systems.
So Pragati starts by structuring what already exists, instead of forcing a new process — allowing us to test, learn, and evolve before adding complexity.
🗺️ Mapping the Assignment Flow
(as it works on ground)
For some context:
So, before jumping into assignment, Pragati first ensures that the transporter can see all their orders in one place, understand what each order needs, and choose which order they want to start working on — making this the natural starting point of the assignment flow.

🎯 After Mapping the Flow,
our Goals were clear.
🧭
Start from existing transporter workflows and bring structure to them
📦
Make order context and details easy to understand
⚡
Enable fast and confident assignment decisions
🧩
Support phase-wise execution of journeys
📱
Preserve transporter control and flexibility
🚚
Maintain a clear view of fleet availability
👉 Key Screens
For some context:
So, before jumping into assignment, Pragati first ensures that the transporter can see all their orders in one place, understand what each order needs, and choose which order they want to start working on — making this the natural starting point of the assignment flow.
Orders irl ; Receive order → Review → Open trip

Phase Assingnment irl; Split Journey → Divide into Smaller Legs → Allocate Responsibility

Order Handling & Tracking irl; Contact Driver /Send Request → Wait for confirmation → Track movement → Monitor status

✨ Reflections & Takeaways
TL;DR : Designing for real life is messy. Logistics is messier. I learned a lot. I’m still learning. And I’d happily do it all over again.
This was my first large-scale, real-world product and my first deep exposure to logistics as a domain. More than anything, it taught me what it actually means to design for real people—people with habits, constraints, workarounds, and years of lived experience. I learned that good design isn’t about perfectly applying frameworks. It’s about understanding the cracks in the system, and shaping solutions that respect how work already happens on the ground.
Working on NETMOS also helped me see design as a collaborative ecosystem. Even if you’re designing for one user, the product is touched by many—transporters, drivers, ops teams, engineers, and stakeholders. Designing with that awareness changed how I think about flows, edge cases, and handoffs.
Beyond design, I walked away with a strong foundational understanding of logistics in the North-East. Most importantly, this project showed me that the goal isn’t to reach a “perfect” solution. The goal is to build the best possible version within real constraints, knowing that meaningful products evolve one thoughtful iteration at a time.
I’m still deeply attached to this project. Not because it’s flawless, but because it represents the moment I truly started thinking like a product designer.