Salesflo Core - 1.2B PKR in daily sales transactions
Company
Salesflo
Year
2017
Scope of Work
Pakistan's B2B sales and distribution market runs on field reps visiting hundreds of outlets daily, logging orders on paper or on phones with no signal, under targets they cannot afford to miss. Salesflo's first MVP tried to digitise that process and failed in the field. Orders were lost, dashboards lagged, and the reps it was built to help found it slower than the paper it was supposed to replace.
I joined as the first designer on the team, with full ownership over product design from day one. I ran the field research, rebuilt the product from the ground up, and over the following two years hired and grew a four-person design team. Salesflo raised $3.1M during this period and grew into Pakistan's leading B2B sales and distribution platform, processing over 1.2B PKR in daily transactions across more than 40 enterprise clients.
01 - The situation
The product that was supposed to help order bookers was making their jobs harder.
Order bookers in Pakistan work under conditions most SaaS products are not designed for. They visit 30 to 50 outlets per day on motorbikes, in 45-degree heat, through areas with little to no mobile signal, carrying daily sales targets they cannot miss. Salesflo's MVP had been built to digitise their order-taking process. In practice it was adding friction to every part of their day. Orders placed without a signal disappeared. Dashboards were slow to load. The interface had not been tested on the entry-level Android devices the reps actually used. Sales performance was suffering and the reps were losing trust in the product before it had a chance to prove itself.
I was brought in as the first designer on the team. There was no design system, no research process, and no documentation of what had failed in the MVP or why. My starting point was the field, not a brief. I spent time shadowing reps on their routes, sitting in distributor backrooms reviewing paper logs, and testing prototypes mid-route to understand what the product needed to survive in the environment it was actually deployed in.
Over the two years that followed I hired four UX designers. Mahrukh led the order booker flows. Raazia, Innama, and Shanzey each took ownership of specific product areas as the platform scaled. This project directly supported Salesflo's $3.1M fundraise and its growth into the leading B2B sales and distribution platform in Pakistan.
02 - The insight
The order bookers were not resistant to the product. They were rational. It simply did not work where they worked.
The assumption going into the field was that the MVP had a usability problem. What I found was something more fundamental. The product had been designed for conditions that did not exist in the field. It assumed a stable connection, a mid-range device, and a rep with time to navigate a multi-step flow. None of those assumptions held. Reps were not avoiding the app out of habit or preference for paper. They were avoiding it because it failed them at the exact moment they needed it most, at a distributor outlet, mid-route, with a queue behind them.
One specific moment confirmed this. I tested a prototype offline, on a low-spec Android, while riding with a rep. The sync state was invisible. When the rep completed an order he had no way of knowing whether it had been saved or lost. He assumed lost. That single observation reshaped the entire design direction. Every subsequent decision about offline behaviour, sync states, and confirmation patterns came back to that moment.
03 - The thinking
We designed for the worst-case scenario first, because that was the only scenario that mattered.
The first and most important call was to design offline-first rather than treating connectivity loss as an edge case. Engineering's initial preference was a connectivity check that paused the flow until signal returned. Field research had shown that low or no signal was not an exception. It was the norm across large parts of the routes reps were covering daily. I argued for a system where every order was saved locally the moment it was placed, sync happened automatically when signal returned, and the rep could see the queue status at any point. The CEO had witnessed this problem directly and aligned immediately when I presented the research. That decision shaped every subsequent architectural choice.
The second call was around scope. I stripped the order booker interface down to the minimum steps needed for the three tasks reps performed most: placing an order, logging a return, and checking a bonus. The alternative was a dashboard-first approach that surfaced all features equally. Field testing showed that approach cost reps 15 to 20 seconds per outlet visit. Across 40 outlets a day that is time against a daily target. Everything outside those three core tasks moved to secondary navigation.
The third call was about the gamified KPI layer. The product team had proposed it as a feature. I pushed for it to be structural. Field reps in this market are motivated by daily targets and peer comparison in ways specific to how distribution sales work in Pakistan. The leaderboard and bonus visibility had to be reachable within two taps from any screen, not buried in a profile section. That positioning was a deliberate decision, not a UI preference.
04 - The design
No design system, no shared standards, and a build that did not match the designs.
In 2017 Salesflo had no design system. No shared components, no spacing rules, no documented typography scale. I was designing in isolation and handing off to engineering without a common reference either side could point to. When the first build came back, the gap was significant. Spacing was inconsistent across screens. Icons had been substituted for alternatives that did not match the intended visual language. Typography varied without a clear logic. During a stress test I ran on the built product, several buttons were not registering taps reliably on the low-spec Android devices the reps used daily.
I worked through the flow screen by screen. The tap target problem was the most urgent. A button that fails a stress test will fail in the field, and a rep who loses an order because of a missed tap will not trust the product a second time. I corrected the targets, rebuilt the spacing on the affected screens, and aligned the iconography back to the original set. That work happened across two rounds of iteration. Round one restored the tap targets and spacing. Round two addressed the typography consistency and the sync state visibility, which usability testing had flagged as a separate problem. Users could not tell whether an order had been saved or was still queued. We made the queue state persistent and visible from the main navigation.
After that build cycle I started documenting every spacing and component decision as a shared reference. It was not a formal design system. It was a working document that both the design and engineering teams could point to. That document became the foundation for how the team worked once I began hiring.
05 - The challenge
The engineering team said it was close enough. I disagreed, and sat with them to fix it.
When the first build came back from engineering, the team's position was that the remaining visual inconsistencies were minor and could be addressed in the next sprint. I understood the pressure they were under. I did not agree with the call. The issues I had found during the stress test were not cosmetic. A button that does not respond reliably under pressure will fail in the field, and a rep who loses an order because of a missed tap will not trust the product again quickly.
I asked to sit directly with the engineers responsible for the affected screens. We worked through the spacing, the tap targets, and the most critical interaction states together in a single session. Some items went to the next sprint. Most were fixed that day. The session changed the dynamic between design and engineering for the rest of the project. It became normal to work through build issues together rather than pass comments back and forth across a handoff document.
What I took from that moment was specific to the absence of shared standards. Without documented component and spacing rules, engineering had reasonable grounds to interpret the designs their way. The disagreement was not about effort or intent. It was a structural problem I had not solved early enough. Sitting with the team fixed the immediate issue. The shared reference document I built afterwards fixed the underlying one.
06 - The outcome
A platform that works in the field, at scale, under real conditions.
The redesigned Salesflo Core shipped and held up in the field in a way the MVP had not. Reps who had been routing around the product started using it as the primary tool for their daily workflow. The metrics reflected that shift.
+21% DAU uplift. Daily active users grew to over 20,000 following the redesign. The offline-first architecture was the primary driver. Reps could complete their full day's work without a reliable connection and the product stopped disappearing from their workflow at the moments it was most needed.
37% improvement in PJP compliance. Journey plan compliance improved as a direct result of the route map feature and the geo-tagging flow. Reps could see their planned route, log new outlets, and retire closed ones directly in the app without breaking their daily sequence.
92% accessibility score on low-specification devices. The stripped interface and large tap targets were validated in usability testing across the entry-level Android devices most commonly used by order bookers, with particular weight on contrast ratios and touch target sizing.
1.2B PKR processed daily. Across 40 enterprise clients and more than 25,000 active users, the platform reached this transaction volume within the period I was leading the design.
Salesflo raised $3.1M during this period. I cannot claim the raise was a design outcome. What I can say is that the platform's reliability and adoption metrics were central to the investor story, and those metrics were built on the decisions made through this project.
07 - The reflection
What I would do differently.
I spent the early part of this project relying on external research. Case studies from other markets, design patterns from products that had solved adjacent problems elsewhere. Some of that was useful as a starting point. None of it was a substitute for what I found in the field. The order bookers in Karachi had a specific set of constraints, cultural habits, and device realities that no published pattern was going to address. I should have gone into the field sooner and stayed longer before touching any interface decisions. The weeks I spent reading about what had worked for field sales apps in other countries were weeks I could have spent watching reps work. Every scenario is different. A similar problem in a different city, let alone a different country, requires a different approach. Salesflo made that concrete for me.
The second thing I would do differently is start the documentation process before development began. I waited until the first build review to realise that the absence of shared standards was creating friction every sprint. A basic shared reference for spacing, components, and interaction states would have changed the dynamic with engineering from the start and reduced the rework in that first build cycle. I built that reference after the problem had already cost the team time. It is now one of the first things I do on any new product, before a single screen goes to engineering.
