What you will learn
Dealer portal requirements should describe how the channel works, not just which screens should exist. The plan has to capture account hierarchy, catalog access, price rules, order data, approvals, support paths, and system ownership.
Access rules come first
A dealer portal has to know which companies, locations, users, roles, territories, and product lines are allowed into each workflow. Access design is the foundation for catalogs, pricing, quotes, documents, and status visibility.
- Dealer company and branch structure
- User roles for buyers, managers, service teams, and sales reps
- Territory, product-line, and account-status restrictions
Catalog and price logic must be testable
Dealer portals fail when pricing and product visibility remain tribal knowledge. The requirements should translate discount tiers, customer-specific catalogs, replacement parts, minimums, and quote-only items into test cases.
- Products each dealer type can see
- Prices, discounts, terms, and exceptions each account receives
- Rules for quote-only, orderable, and unavailable items
Order quality matters more than checkout polish
The portal should collect enough context for downstream teams to act without reinterpreting the order. That means purchase order numbers, ship-to details, freight notes, requested dates, configurations, substitutions, and approval history may matter more than a conventional cart flow.
- Required order fields by order type
- Quote review and approval thresholds
- ERP, warehouse, and customer service handoff needs
Status visibility must be trustworthy
Dealers adopt portals when the portal knows what customer service would otherwise have to look up. Order history, allocations, shipment status, invoices, returns, and service documents should be tied to reliable system data.
- Order and quote history
- Inventory confidence and allocation signals
- Shipment, delivery, return, and invoice visibility