“We need a CRM” can mean almost anything: a shared list of leads, an order book for a sales team on the road, a full system that replaces spreadsheets, WhatsApp groups and a notebook. Big requirement documents try to capture all of that up front, and they usually fail — they're too long to read, too abstract to price, and out of date by the time building starts.
Here's the lighter process we use to scope business software, including the one we used for our own wholesale CRM, Plog.
Step 1: Sit with the people who'll use it
Before any screen or feature list, we spend time with the people who will use the software every day — the sales rep, the accounts person, the owner. We ask them to walk us through a real day, using the tools they have now.
We're listening for three things:
- The moments of friction. Where do they copy the same information twice? Where do they wait for someone else?
- The workarounds. A notebook of dues, a WhatsApp group for orders, a spreadsheet only one person understands. Workarounds are requirements in disguise.
- The questions the owner can't answer quickly. “Which retailers haven't ordered this month?” If that takes an afternoon, it's a feature.
Step 2: Map the work, not the features
Next, we draw the workflow on a single page: who does what, in what order, and what information passes between them. For a distributor, it might look like this:
- A sales rep visits a retailer and books an order.
- The office confirms stock and prices.
- The warehouse dispatches.
- Accounts records the invoice and tracks payment.
- The rep collects dues on the next visit.
Every box becomes a screen or an action; every arrow becomes a notification or a status. This one page does more to align everyone than a long document, because people can point at it and say “no, that's not how it works”.
A one-page workflow people argue about is worth more than a sixty-page document nobody reads.
Step 3: Cut to a first release
Now we separate what the first release must do from what can wait. We use three simple buckets:
| Bucket | Question it answers | Example |
|---|---|---|
| Must have | Can the business run on it from day one? | Book an order, see dues per retailer |
| Soon after | Will people ask for it within a month? | Route planning for visits |
| Later | Nice, but nobody is blocked without it | Advanced sales forecasting |
The first release is only the “must have” bucket. It's smaller than people expect, and that's the point: it gets into real hands quickly, and real use tells us what to build next far better than guesses.
Step 4: Decide the non-negotiables
Some things aren't features but still shape the build, so we agree on them explicitly:
- Roles and permissions. Who can see prices, edit orders, or change a retailer's credit limit?
- Audit trail. Who changed what, and when? For anything involving money, this is essential.
- Offline behaviour. Will reps book orders where the signal is weak? Then the app has to work offline and sync later.
- Integrations. Payments, accounting software, SMS or WhatsApp notifications — each one is listed with what exactly needs to flow in which direction.
- Data you already have. Existing customer lists and balances need to be imported cleanly on day one.
Step 5: Write a scope people will actually read
The written scope we send is short. It usually fits in a few pages:
- The one-page workflow.
- The first-release feature list, with each item described in a sentence or two.
- The non-negotiables above.
- Milestones, with what you'll be able to see and test at each one.
- A fixed quote for the first release, and a rough range for the “soon after” bucket.
Because it's short, the owner, the sales lead and the accounts person can all read it and agree to it — which is the real purpose of a scope.
Step 6: Build in milestones, review with real data
We build in milestones of a couple of weeks, each ending with something usable. Where we can, we test with a copy of your real data, because fake data hides the messy cases — the retailer with three phone numbers, the product with seventeen variants.
Why this works
Long documents try to remove uncertainty by describing everything. We'd rather reduce it by learning quickly: watch the work, map it on a page, ship the smallest useful version, and let real use guide the rest. It's faster, cheaper, and the software ends up fitting the business instead of the document.
If your team is running on spreadsheets and WhatsApp groups, that's a perfectly good starting point. Tell us how a day works, and we'll send back a scope you can read in ten minutes.
Leave a Reply