Why a dealer channel is a separate product
A dealer order often begins outside an online shop. A manager receives an email or a photograph of a list, checks the price and stock in an accounting system, re-enters the lines, and sends an invoice. The routine appears manageable at low volume. As the product range and partner network grow, the business pays for repeated entry, waiting, and conflicting price-list versions.
Current search results for B2B portal development reveal a stable set of expectations. Letary describes roles and CRM/1C connections, while BB Studio presents a manufacturer catalogue with technical documents, a dealer account, and quotation requests. These are suppliers’ claims, not proof of customer outcomes. They nevertheless show that buyers are looking for a new way to work with partners rather than simply another website.
The first executive decision is to name the process the portal must replace. If a manager still types every portal order into 1C and the dealer still calls for current stock, the company has bought a new interface on top of the old manual operation.
A scenario is more useful than a feature list
“Account, catalogue, and integration” is not enough detail for an estimate. A visible path is needed: an employee signs in for a known partner organisation, sees that organisation’s range and prices, creates an order, receives confirmation, and later finds its status and documents. Each step needs a source of truth, an owner, and defined error behaviour.
Roles are usually broader than administrator and user. A dealer may have a buyer and approver with different limits; the manufacturer may involve sales, finance, warehouse, and support. The portal should preserve who created, approved, or changed an order. A shared department login removes that history and makes a disputed operation harder to resolve.
The first release does not need to reproduce every sales operation. Three or four completed common scenarios are more useful than twenty sections that end with “call your manager”. A rare exception can go to a person for now, provided the portal carries the context forward instead of forcing the dealer to start again.
A 1C exchange is a data contract
In a first-party 1C integration example, a website and database exchange messages through 1C:ESB with configured addresses, keys, and request checks. A particular project may use another mechanism, but the principle is the same: the portal does not read “1C in general”. Two systems exchange named objects under explicit rules.
Before estimating, decide which system owns the product, price, stock, counterparty, order, payment, and shipment. If both portal and 1C can independently change a price, conflict is inevitable. If stock refreshes hourly, the interface must not promise exact availability “now”. If an order was accepted but the response was lost, retrying must not create a second order.
That is why the risky exchange should be prototyped before the main build. Use several real products, price types, and counterparties, send an order into a test database, interrupt the connection deliberately, and verify recovery. This produces more useful estimate evidence than dozens of polished screens for an unproven flow.
What belongs in a workable first release
Turn every item into an acceptance condition. Not “stock is shown”, but “the dealer sees when it was refreshed and gets an honest fallback when 1C is unavailable”. Not “documents exist”, but “only the right organisation can open the document, its version matches the accounting system, and revoked access stops working”.
Test separately with two or three real partners. Internal staff know the manufacturer’s abbreviations and rules; a dealer may search by another product name, misunderstand a status, or expect to repeat a previous order in one action. Those differences cost less to discover before a general launch.
- Dealer-employee sign-in, organisation binding, roles, and access removal when an employee leaves.
- A catalogue with attributes and documents available to the relevant partner group.
- Partner-specific prices and a visible stock freshness time.
- Order creation and repeat ordering, receipt confirmation, and duplicate protection.
- Fulfilment status, invoices, or delivery documents where the accounting system genuinely supplies them.
- An employee workspace that shows exchange errors and lets staff help without losing context.
- Important-action logs, integration monitoring, backups, and a testable release process.
Why two proposals with the same label are not comparable
Cost grows with the number of roles, pricing rules, catalogue condition, authentication methods, data exchanges, documents, load, and recovery requirements. A private catalogue with an enquiry form and a two-way ordering channel may share a label, but they need different architecture, testing, and support.
pommeDeTerre’s current price list starts a web-service first release at RUB 300,000, covering up to five primary scenarios, authentication, and a limited-group launch. This is a lower-bound guide, not the price of every dealer portal: 1C integration, complex pricing, documents, and several roles may move the project into the next scope. A defensible estimate follows examination of the data and the risky exchange.
A supplier proposal should separate discovery, integration prototype, first release, data migration, launch, and continued operation. The executive can then see both the development budget and the point at which a limited dealer group can test value before more features are funded. A portal becomes a business system not when it has many screens, but when one order travels from a partner’s terms into the accounting record without being typed again.