Workflow guide
Mapping a distributor's rep-to-order workflow: leads, samples, orders and reorders
A packaged ordering tool answers login and catalog. The harder questions are about samples, pricing exceptions and who owns what between your CRM and your ERP. This is the worksheet we use before any of that gets decided.
Why "add a portal" undersells the problem
Most distributors already have an order system, an ERP, or both. Most distributors already have software. The gap is that the software does not match how a rep actually works an account, or how a retailer or dealer buyer actually reorders.
A packaged ordering tool or portal answers a narrow question well: can a buyer log in and place an order against a catalog. It usually has less to say about a sample that has not been followed up, a price that only applies to one account, or what happens when a reorder needs an exception. Those are the parts that end up back in a spreadsheet.
This worksheet is the list of questions we ask before deciding whether to build, extend what you have, or leave a workflow exactly as it is. It is useful whether or not you ever talk to us.
The path has four stages, and each one has its own questions
Write down your current answer for each stage before you decide anything about tools. Where the honest answer is "it depends on the rep" or "nobody wrote it down," that is the finding. Write it down as the answer.
1. Lead: how a new account gets on the map
- Who records a new retailer or dealer today, and in what system, if any.
- What has to be true before a rep can start selling to it: a credit check, a territory assignment, a brand authorization.
- Whether locations under one retailer, such as separate stores or branches, are already modeled anywhere, or whether each one gets entered separately.
2. Sample: what happens between "yes" and the first order
- How a sample gets requested, approved and shipped, and who does each step.
- Who is responsible for the follow-up, and by when. If the answer is "the rep remembers," write that down plainly.
- Whether a review calendar or a target reorder date is tracked anywhere consistently, or lives in one person's head.
3. Order: where pricing and inventory actually live
- Which system has the final say on price for a given account: list price, a negotiated contract price, a promotional rate, a one-off approval.
- What gets checked before an order is accepted: credit standing, live inventory, minimum order size.
- Whether totals and payment rules are enforced in one place, or calculated twice in two systems that can disagree.
4. Reorder: what a buyer can do without calling a rep
- Whether a retailer or dealer buyer can already see their own order history, pricing and shipment status, or whether every question is a phone call.
- What a rep still has to do by hand for a routine reorder that has no exceptions.
- What happens when a reorder does need an exception: a backorder, a price change, a split shipment. Who decides, and how does the decision reach the order.
Where the ERP boundary usually falls
Most distributors already run an ERP for inventory, pricing and invoicing, and rightly do not want a second copy of that. The question is not whether to replace the ERP. It is which system owns which decision.
| Usually stays in the ERP | Usually belongs in the CRM or portal |
|---|---|
| Inventory levels and availability | The relationship history: visits, samples, follow-ups |
| Standard pricing and invoicing | Account-specific exceptions and their approval trail |
| Purchase orders and shipment records | What the rep or buyer sees, and when they see it |
| Financial reconciliation | Territory and coverage: who owns which account |
Treat this table as a starting point. Every distributor has at least one item that seems to belong on the other side because of how a specific system was configured years ago. Finding those is most of the value of doing this exercise with your own team instead of assuming the general case applies.
Permissions and approvals
Write these down before choosing any system, because they usually reveal more than the workflow map does:
- Which roles exist among your reps, order staff and finance team, in plain language, not as software permissions.
- Who can see or change a price, and who has to approve an exception before it reaches an order.
- Which records are restricted for a reason: a confidential contract price, a credit hold, a legal or compliance matter.
It is common to find that the current rule lives only in one experienced person's judgment. That is worth knowing before you build anything that has to enforce a rule nobody has written down yet.
How this looks in one working system
David runs beLoved Health, a distribution company, and built the system it runs on. Its accounts, locations, samples, brand and rep routes, and wholesale order history are one answer to the questions above, not the only correct one. It used to run on Salesforce; the move off it is documented in the system's own records. We have not measured rep time or order volume against the earlier setup, and this worksheet does not depend on that system being the right shape for your business. If you want to see how one distributor answered these questions, ask us.
Common mistakes
- Buying a portal before mapping the pricing exceptions. A login screen does not resolve who is allowed to override a price.
- Assuming the ERP already tracks samples. Most ERPs were not built for a sample-to-order path, and the tracking quietly moves to a spreadsheet.
- Letting the rep be the only record of what happened on an account. When that rep leaves, the account's history leaves with them.
- Building reorder self-service before deciding who approves an exception. Buyers find the one case the system cannot handle within a week.
- Skipping the permissions question until something goes wrong. It is cheaper to answer before a pricing mistake than after one.
Using this with us, or without us
This worksheet is useful whatever you decide, including staying with the tools you run today. If you want help, we do it with you as the second step of our process, after a discovery call, and you keep the result either way.