The question
We were building our first mobile app and had to decide what went on it. The two candidates were our CRM and our pricing workflow, and the obvious answer turned out to be the wrong one.
How a field salesperson actually works
Our CRM is where freight-forwarder sales teams manage leads, customers and sales activity. It was a web product, built for someone at a desk.
Their salespeople aren't at a desk. They spend the day visiting exporters and importers, taking calls between meetings and collecting business cards in receptions. The work happens in the field and the record of it lived on a laptop back at the office.
What I thought was going on
Adoption was low and the easy read was that field sales didn't see the point of a CRM.
When I spoke to sales teams across our SMB and enterprise accounts, that wasn't what was happening. They were updating the CRM on Friday, for the whole week, from memory — not because they were lazy, but because it was the first time they were near a laptop with time to do it. They did it because management needed the reports.
So everything in our CRM was reconstructed days after the fact. Management was running pipeline reviews off it, and the salesperson got nothing back for the effort.
The product wasn't missing information. It just wasn't available at the moment the work happened.
The argument about what to build first
Internally, pricing was the favourite. Our web pricing workflow was already heavily used, so the demand was proven and mobile felt like a safe extension of something working.
I looked at who each option would actually serve. In a 60-person enterprise account, pricing is used by two or three people. They sit at a desk all day and already like the web version — a phone wouldn't change how they work. The same account has ten to fifteen salespeople who are almost never at a desk.
The point wasn't that CRM had more users. It was that pricing on mobile is the same workflow on a smaller screen, while CRM on mobile changes when the work gets captured at all. I took that to the team and we started with CRM.
Deciding what went into the first version
The temptation was to rebuild the whole web CRM on a phone. That would have failed for the same reason the web version failed — a salesperson between meetings doesn't have the time or attention to fill in a full record.
So we kept the first version to things that could be done in the few seconds right after a meeting or a call. With guidance from my Product Head, that came down to three:
Scanning a business card instead of typing four fields into a form.
Calling from inside the app, since the call was happening anyway — doing it here meant we knew it happened without anyone logging it.
Prompting for a summary the moment the call ended. A short summary recorded straight after the call is more accurate than a longer one written on Friday.
Around those we put the bare minimum to make the app usable in the field: lead profile, recent activity, and the sales numbers a manager asks about.
The idea was to capture the work as it happened, instead of asking salespeople to write it up later.
What using it actually taught us
I ran betas with customers, visited their offices, and came back after two or three days. The useful question wasn't whether they liked the app — it was what they'd actually done with it the day before.
Two things came out of it. Salespeople were opening leads one at a time to remember who they were, so we moved the key details and the latest activity onto the lead overview and the list itself.
The second was the card scanner. We'd built it for one side of a card. Customers showed us that in this industry the back of the card carries real information — other office locations, additional numbers, sometimes the details in another language. Obvious in hindsight, and we only found it because someone scanned a card in front of me and then turned it over. We shipped a second version for front-and-back.
Where it stands
After the beta I worked with Customer Success and marketing on a rollout focused on enterprise accounts, and ran the demos and onboarding myself. Over 50 salespeople who had been tracking their pipeline manually came onto the product, and some customers bought Shipmnts specifically because the mobile app made the CRM usable for their field teams.
Mobile has since gone well beyond CRM — inquiry, quotation, pricing, shipment creation and milestone tracking all run on it now.
What I'd do differently: I knew what problem we were solving and I still designed the card scanner from a problem statement instead of from watching someone hold a card. For a 0-to-1 product, knowing what needs to be solved isn't the same as knowing how the work actually gets done.