Distributor Portals: Trade Accounts, Pricing and Stock Visibility

What determines a distributor portal’s scope and cost

When planning a distributor portal, consider how trade accounts are approved and managed, how customer-specific prices are applied, how current stock information needs to be, and how the portal connects to existing systems and order fulfilment. Define these alongside the pages and functions the portal needs. To assess a proposal, define the operating rules and dependencies first, then agree what belongs in the first phase.

Map the decisions that shape the work:

• Accounts: who approves an application, what information they need, and which users can act for each account.
• Pricing: where customer prices and discounts come from, which rules take priority, and what happens when a price is missing or disputed.
• Stock: what customers should see, how fresh that information must be, and how to handle stock that changes before an order is processed.
• Systems and fulfilment: which existing systems hold account, product, price and stock data, and how an online order reaches the people who pick, confirm or amend it.

Record these answers when discussing discovery, configuration or development, data preparation and testing with suppliers. Separate that project scope from ongoing needs such as hosting, support and maintenance; the right arrangements depend on how the portal will be operated.

Before seeking proposals, decide which rules and order path are essential at launch and which can wait. Ask each supplier to address the same requirements and exclusions so you can compare scope rather than feature labels. This is a qualitative guide, not a price estimate: a supplier proposal needs to reflect your systems, data and working processes.

How account approval and customer pricing change the scope

When planning a portal for customers with different ways of working, define account approval and customer pricing requirements. Before asking a supplier to estimate the work, make the decisions below explicit; the portal can implement agreed commercial rules, but it should not be expected to decide them for you.

• Registration and approval: Map what a prospective trade customer submits, such as business and contact details, and who reviews the request. Decide whether every application needs manual approval or whether some can be approved against criteria your business has defined. Specify what happens when information is incomplete, an application is declined or an existing account is suspended. If these steps vary by customer type or branch, show the variations rather than describing only the usual case.
• Account status and permissions: List the actions available to an approved, pending or suspended account. For example, decide whether users can browse prices, place orders, see past orders or manage account users. Consider whether one customer account has several buyers, and whether they all need the same access. If a representative needs to view or order for several customers, describe how that relationship is approved and managed. List the roles and exceptions the portal needs to support, and describe how each should be handled.
• Price lists and customer tiers: Record how a product’s price is determined for each customer: by an assigned list, tier, discount or another agreed rule. Identify where each rule is maintained today, who owns it and how often it changes. Give suppliers representative examples, including a customer with standard pricing and one with negotiated terms, so they can understand what the portal must display and apply.
• Discounts and exceptions: Document how promotions, product-specific deals, account exceptions and overlapping rules should be handled. State which rule takes priority and what the user should see if pricing information is missing or conflicting. Informal arrangements held in emails or staff knowledge can be difficult to reproduce consistently. Where commercially appropriate, standardise or retire exceptions rather than assuming each one must be automated.
• Ownership and change: Name the business role responsible for approving changes to account access and pricing rules, and explain how those changes reach the portal. Decide who checks that a change has taken effect as intended. Describe the initial setup and the ongoing work of maintaining accurate information.

For a useful proposal, ask suppliers to show which account and pricing decisions their scope assumes, which cases need bespoke handling and what they have left out. That makes it easier to compare approaches without asking a supplier to set your prices or credit terms.

Stock visibility depends on data and system connections

Stock visibility is not just a matter of copying a quantity into a portal. First decide what the figure should tell a trade customer, which system is authoritative for it and how the portal should behave when the information is delayed or unavailable.

• Define what “in stock” means. Decide whether customers should see available stock, stock by location, expected availability or another measure. A quantity held in a warehouse may not be available to promise if it is reserved, allocated or subject to an internal rule. Agree the wording and meaning with the people who take orders and manage fulfilment.
• Set an acceptable level of freshness. Ask how current stock information needs to be for customers to place useful orders. Consider what happens if a customer orders against a figure that has since changed, or if the portal cannot retrieve an update. The business must decide whether to show the last known figure, hide it, or direct the customer to another ordering route, and how staff will handle resulting enquiries.
• Map the order rules that affect stock. Reservations, back-orders, order limits and cut-off rules can change what a customer is allowed to order and what happens next. Trace a typical order from the portal through internal processing: identify when stock is checked or reserved, what happens when the requested quantity is unavailable, and which team handles an exception. Confirm whether these decisions belong in the portal, an existing system or a staff process.
• List the information sources. Map the ERP, accounting, inventory, product and delivery systems that hold relevant information. For each one, record what data is needed and who uses it. Do not assume every system needs its own direct connection: a supplier should explain which information must move between systems and what alternatives are practical for your workflow.
• Agree data ownership and quality. Identify the authoritative source for product identifiers, customer records, units of measure and stock figures. Look for duplicate records, missing fields or inconsistent units that could make a displayed quantity misleading or prevent an order being matched correctly. Decide who can correct each issue and whether existing records need to be cleaned up before they are used in the portal.
• Ask how each connection will operate. For every proposed data flow, ask what moves, in which direction, when it updates and how staff will see an error. Clarify who investigates failed updates, corrects source data and confirms that normal processing has resumed. Clarify these responsibilities so staff know how to handle updates and corrections.
• Include operational changes in the scope. Include data quality and stock-handling procedures in the scope alongside building the portal. Ask suppliers to identify those dependencies separately, explain what the business must provide and show which stock features could be deferred without making the first ordering workflow unreliable.

Use this scope-to-cost breakdown to expose the work

Use the breakdown below to turn the account, pricing and stock rules already identified into questions suppliers can estimate against. It is a scoping aid, not a numeric estimate: ask each supplier to state its assumptions and exclusions for every area, including who is responsible for work on your existing systems and data.

Choose between custom development, an existing platform and a simpler process

Choose the least complex option that can handle the order path your customers and staff actually use. A configured or extended platform may be enough if its available capabilities and your existing systems can support the account, pricing, stock and ordering rules. Custom development is worth investigating when important rules or connections do not fit; keeping assisted ordering is also a valid choice if a separate portal would add more work than it removes.

Ask each supplier to demonstrate the same documented scenario: a new trade account is approved, sees its applicable price and stock information, submits an order, and the order reaches the team or system that fulfils it. Note where the option needs manual steps, exceptions or assumptions. Broad feature labels are less useful than seeing your actual rules handled.

The decision need not be all-or-nothing. You could assess a configured approach or a limited first phase alongside custom work, then defer features that are not needed to complete the core order path. If the documented requirements point towards tailored software, compare proposals against the same scenarios and ownership questions.

Prioritise the first phase around a complete order path

Use a complete order path to decide what belongs in the first phase. The aim is not to include every requested feature, but to confirm that representative customers can place orders accurately and staff can process them safely.

1. Write one end-to-end scenario. For example, an approved trade account signs in, finds a product, sees the price and stock information intended for that account, places an order, and the order reaches the right business team or system for processing. Note what each person or system must do at every hand-off.
2. Sort each requirement into three groups. Mark whether it is needed to complete the order path, needed for reliable day-to-day operation, or a later convenience. Commercial and operational owners should agree the categories so priorities reflect both customer ordering and order fulfilment needs.
3. Include representative rules, not just the simplest case. Choose account types, pricing cases and stock outcomes that reflect how orders are actually handled. Specify the minimum information and system connections needed for those cases, including what staff must see when data is missing or an order cannot proceed.
4. Make exceptions explicit. For each exception, decide whether the portal must handle it automatically in the first phase, whether staff can follow a documented manual process, or whether it can wait. Examples might include an account awaiting approval, an unavailable item or a price that needs checking.
5. Check that deferrals leave a workable process. If account changes or unusual orders are handled manually at first, name who receives them, what information they need and how the outcome is recorded. Do not defer a feature if that leaves orders unowned or staff relying on unclear workarounds.
6. Test the assumptions before finalising proposals. Walk through a small set of scenarios with the people who approve accounts, manage prices, handle stock and process orders. Record where the rules or data are uncertain so suppliers can state how they have allowed for them.
7. Keep detailed interface choices separate. Decide what the first phase must let customers and staff accomplish; defer detailed screen and interaction decisions to the design work.

Prepare a brief that makes supplier proposals comparable

Give each supplier the same concise brief, so differences in their proposals reflect the work and assumptions rather than gaps in the information provided. Use this checklist to make the requirements, dependencies and ongoing responsibilities visible.

• Systems and data: List each current system, what it is used for, which information it holds and who is responsible for it. Include known data-quality issues, such as duplicate customer records, inconsistent product identifiers or stock figures that need checking.
• Accounts and pricing: Describe account types, how a new trade account is approved, which users can place or manage orders, and how permissions are assigned. Explain pricing structures and exceptions, including who confirms a rule when an account’s agreed price or discount is missing or disputed.
• Stock and availability: Specify what customers should see, such as availability by product or location, and how current the information needs to be for your business. State how reservations, back-orders and unavailable or delayed stock data should be handled, and who decides what the customer sees when information cannot be confirmed.
• Order journey: Map what happens from customer submission through internal review and processing. Note relevant cut-offs, order limits, repeat-order needs and any use of account statements. Identify where staff check, amend or approve an order, and how the customer is told about an issue.
• First phase and deferrals: Mark requirements that are essential for a complete first-phase order path separately from later options. Name any manual step that will remain, who will carry it out and how exceptions will be passed to them. This makes clear whether a proposed first phase is workable without every feature.
• Proposal response: Ask every supplier to respond against the same areas: included work, assumptions, exclusions, dependencies, testing responsibilities and ongoing operating needs. Request a clear distinction between project work and hosting, maintenance and support, plus an explanation of how changes to pricing rules or integrations would be handled.
• Comparison: Compare completeness and fit, not just headline scope. Check that each response addresses the same account, pricing, stock and order scenarios. Where assumptions differ or an area is excluded, ask for clarification before treating the proposals as comparable.

Once the requirements are defined, you can request a project quote based on the same brief you use to assess other supplier responses.

Include ownership and ongoing operation in the decision

Before commissioning the portal, agree who will run it once customers start placing orders. Add these responsibilities to the brief and ask suppliers to state what they include and what remains with your business.

• Hosting and maintenance: Clarify who looks after the environment, applies updates and deals with faults, and what ongoing support is available.
• Integration monitoring: Name who checks that orders, prices and stock information move between the portal and your business systems, and who investigates when a connection fails or data is delayed.
• Data ownership: Assign a business owner for customer accounts, product records, prices and stock data. Make clear who corrects errors and approves changes.
• Account and pricing rules: Decide who can approve new trade accounts, change customer-specific terms and resolve exceptions, including when the responsible person is unavailable.
• Customer and staff support: Agree who handles ordering problems, updates customers and records issues that need technical attention.
• Handover and change: Ask what documentation, access and training your staff will receive, and how future changes to workflows or systems will be handled.

Plan for ongoing work after launch and agree who will manage it. Compare proposals on these responsibilities as well as the initial build. Proceed when you can define the core order path, its essential rules and data sources, and who will own the service; if not, resolve those points before commissioning.