Why a B2B customer portal hits a wall with manual order processing
As long as orders arrive by email and in messengers, and the price list lives in a separate file, the process rests on one person.
The customer sends a request in free form — the manager manually looks up the item in the catalog, checks warehouse stock, recalls the personal discount and transfers everything into an invoice. With five buyers the scheme works; at twenty it starts failing every day.
A B2B customer portal removes manual order processing from this chain — but only if it is built around real data rather than around a request form.
Prices, stock, shipment history and contract terms must come from the accounting system at the moment of viewing, while the cart and the order must be saved back into it transactionally.
Otherwise the portal becomes just another storefront, and the manager still reconciles everything by hand.
Mismatches are what cost the most. Errors in prices and stock are almost always a consequence of the price list, the warehouse and contract terms living in different places and updating at different times.
The customer orders an item that is already out of stock, or at a price that changed that morning — and then follows the back-and-forth, the invoice recalculation, the cancellation.
Duplicate orders appear in the same place: a request went out by email, was duplicated in a messenger, and the manager entered both.
On top of that comes the load on managers, which grows faster than turnover. Every new buyer is another request format, another set of exceptions for discounts and deferred payment, another manual check.
The bottleneck stops being technical and becomes organizational: to process twice as many orders you need twice as many people, not a system that is twice as fast.
All these failures share one root cause — there is no single source of truth for the catalog, prices and available stock that both the customer and the warehouse read from.
We break down how this is solved in a B2B customer portal and exactly what needs to be synchronized so that manual order processing leaves the process.
What changes after launch: order time, error rate, workload
Moving orders to self-service shows up in four numbers, which we take before and after launch. The first is repeat order speed: the buyer opens their purchase history, copies a previous delivery into the cart and changes only the quantity. An order that used to stretch into a day of back-and-forth now takes a couple of minutes.
The second is the share of manual operations.
Contract prices, limits, deferred payment and stock at the shipping warehouse are pulled into the portal from the accounting system, so the manager does not reconcile items by hand and does not transfer a request from an email into an invoice.
A self-service customer order closes the standard cycle on its own: selection from the assigned price list, confirmation and transfer to the accounting system.
The third is a whole class of failures that disappears. A price or stock mismatch between the catalog and the accounting system used to surface after confirmation: the customer had approved the total, and some items were out of stock.
Verification at the moment of ordering and a reserve for the picking period remove this scenario — the request is assembled only from what is available.
The fourth is fewer order errors thanks to access rules: the buyer sees only their own catalog and their own terms, while on the 1C-Bitrix side it is recorded who placed the request and under which contract.
The load on managers shifts from order entry to exceptions — non-standard items and discount approvals.
We take the metrics from logs, not by eye: time from entering the portal to submitting an order, the share of orders with no manager edits, the number of edits after confirmation. These three metrics become the acceptance criteria.
Three ways to implement a B2B portal and their limitations
At the start there is almost always one question: what to hand over to the out-of-the-box functionality of 1C-Bitrix and what to build ourselves.
The standard functionality covers the basics — linking employees to a company, separate prices per contract, order history, invoices and documents, roles and purchasing limits.
The gaps start with non-standard requirements: multi-level approval, volume-based pricing and payment deferrals, limits by department.
It is worth comparing B2B portal implementation options before the first line of code: rewriting the pricing and access layer on a live portal costs more than choosing the right architecture from the start.
| Option | When it fits | Limitations |
|---|---|---|
| Out-of-the-box platform functionality | Basic procurement: legal entities, contract prices, repeat orders, documents | Pricing and approval rules are set by the core; complex schemes are worked around manually |
| Extending the current portal | The catalog, orders and exchange with the accounting system already work; non-standard needs are local | Code coupling grows; platform updates require migrating customizations |
| A separate environment | Pricing and approval rules do not fit the platform: discount grids, tenders, budget limits | Requires exchange of reference data and stock; two places for access rights and audit |
The practical criterion is the share of scenarios that fit the standard model. If the non-standard part is only in pricing, while orders and documents are typical, extending the portal is cheaper to maintain.
When your own rules affect pricing, calculations and roles all at once, a separate environment is more predictable: core updates do not conflict with your logic.
Implementation stages: scenario audit, exchange scheme, configuration, verification
Implementing a B2B customer portal is not installing a ready-made module but rebuilding the way an order travels from request to shipment and closing documents.
We work in stages, and each ends with a verifiable result: it can be accepted, challenged or sent back for revision before it drags the rest along with it.
- Order process audit. We analyze the actual scenarios: which of the customer's employees creates a request, who approves it, where accounting gets involved, how orders are currently transmitted and how history is kept. The output is a map of roles, limits and approval points, plus a list of operations that should move out of email threads and into the portal.
- Data exchange scheme. We determine which entities are synchronized — counterparties, contracts, catalog items, prices, stock, order statuses — in which direction and how often. We separately define the record matching rules and the behavior on a mismatch, so that duplicates and "lost" items do not appear.
- Building an end-to-end scenario on a test environment. We implement one complete path — from selecting items from purchase history to order confirmation — and agree on the logic before it spreads across all sections of the portal.
- Configuring roles and permissions. We separate access by organization, department and employee: who can see prices and outstanding debt, who works only with their own orders, who sees data across the entire group of companies.
- Exchange and exception handling. We configure the document transfer queue, retries and an error log: a single connectivity failure must not result in an order failing to reach the accounting system.
- Acceptance testing on real data. We run a copy of the production database on actual orders and reconcile the results with the accounting system — by amounts, statuses, stock and access rights. We resolve discrepancies down to zero rather than "fixing them along the way".
- Launch and training. We move the configuration to the production environment, train managers and key customers, and hand over the exchange regulations and the procedure for failures. For the first week after launch we provide heightened support — this way problems are caught before customers notice them.
What we hand over: configurations, roles, exchange schemes, regulations
The result of the work is not only a working portal but also documentation your team can use to maintain it without us.
Below is the list of what the acceptance package includes: without these items the portal works, but any change — a new user, a new price, an export failure — again requires the contractor.
- Environment configuration and settings map: which exchange queues are enabled, where connection parameters are stored, which admin sections are responsible for what.
- Counterparty access rights matrix — a "role / what they see / what they can change" table: purchaser, head of the organization, accountant, manager, restriction of the selection to their own counterparty and list of warehouses.
- Roles and access separation in the admin area: who manages users, who only reads requests, who approves prices — so that employees of one counterparty do not see other companies' orders and stock.
- Exchange scheme with the accounting system: direction of flows (catalog, prices, stock, orders, statuses), frequency, which system is the master and how a mismatch is resolved.
- Exchange regulations: the procedure for an export error, restart, the exchange log and the signs by which the on-duty engineer understands that data has stopped flowing.
- Instructions for managers: creating a user and linking them to a counterparty, granting and revoking access, typical customer questions with ready-made answers.
- Portal documentation: description of sections, integration map, where to look at logs, a post-release check list.
The documentation lives alongside the portal and is updated with each change. During handover we run a walkthrough with your team — so the instructions do not remain an unread file on disk.
Case study: a wholesale supplier eliminated manual order entry
A wholesale supplier with a base of regular customers took orders by email and phone: a manager manually transferred items from the email into the accounting system, checked stock and prices, and confirmed each line.
On a long specification a single order took up to forty minutes, and discrepancies in SKUs and prices surfaced during picking — they were closed by re-agreeing with the customer and re-checking the warehouse.
We built a B2B portal on 1C-Bitrix with a customer portal: the client sees their own catalog, personal terms and stock, assembles an order and repeats past purchases in a couple of actions.
Orders go directly into the accounting system with no manual transfer, the customer tracks statuses and documents themselves, and the manager gets involved only for non-standard terms and new contracts.
| What we measured | Before the portal | After |
|---|---|---|
| How orders are taken | email, phone | self-service in the portal |
| Processing time for one request | 30–40 minutes | 5–8 minutes |
| Share of orders with an error in items or prices | about 12% | less than 2% |
| Share of orders placed by the customer independently | none | 7 out of 10 |
| What the manager spends time on | manual entry and reconciliation | non-standard orders, new customers |
We compared order logs for comparable periods before and after launch, and counted repeat purchases separately — their share grew because customers no longer had to wait for a reply to an email.
Manual entry left the process: a wrong SKU is now caught at the selection stage, not in the warehouse.
What to do if your customers already work on an old portal
An old portal is not switched off on a single date: first comes an inventory of what actually keeps sales running — customer accounts, contracts, agreed prices, limits and order history.
In 1C-Bitrix these are separate entities linked to each other, so migration is not a single export but follows the relationships.
Then we fix the source of truth: if prices and stock are calculated in the accounting system, what is migrated into the new portal is not a copy but a link to it.
Customer data is migrated by a matching key — login, email address, company tax ID. This way the customer logs in with familiar credentials and sees their purchase history, linked contracts and personal terms rather than an empty profile.
In-progress orders are migrated with their numbers and statuses, so that accounting and the warehouse do not have to reconcile documents in two places by hand.
Phased transition: the new portal first opens for a limited group of buyers in read-only mode — catalog, prices, history. Then we enable order placement and repeat purchases, and only after reconciliation do we close order acceptance on the old portal.
It remains available for viewing and export — a rollback does not require restoring from a backup and does not bring sales down.
Keeping current orders intact is solved like this: orders placed before the switch are completed to closure in the previous environment, while new ones go straight to the new portal. We'll break down how to set this up on your portal without stopping sales.
Technical concerns before the start: access, load, exchange
Before the start the same questions almost always come up: who sees what in the portal, what happens to orders when the accounting system is unavailable, will the portal handle the seasonal peak in orders and how does it live on after launch.
We answer them before the first line of code — otherwise decisions are made in a hurry and redone on live users.
How are access rights and roles separated?
We build rights on roles rather than listing individual users: wholesale and retail price, separate catalog, order history, amount limits. The role is assigned by the customer's manager — a new employee is onboarded without code changes.
For internal employees we enable two-factor authentication, and actions with prices and documents are written to a log.
What happens if the accounting system is unavailable?
The exchange does not go down with it: orders, registrations and requests go into a queue and are retried with increasing intervals until a response.
An order key makes retries safe — no duplicates appear in the accounting system, and the customer sees an "accepted, processing" status instead of an error.
Will the portal handle the seasonal peak?
The catalog and personal prices are cached, heavy queries are precomputed, and reads are separated from writes. The peak then loads the exchange queue instead of bringing down the portal's storefront.
Who runs the portal after launch?
We hand over the exchange scheme, role descriptions, the release procedure and a list of metrics: exchange errors, queue delay, section response time. Monitoring is configured around them, so engineers learn about a failure before a customer writes to support.
Let's discuss your task and come back with an estimate, scheme and work plan
To keep the conversation concrete, it is enough to prepare three things for the discussion: a list of the roles that will work in the portal, the key scenarios (order, approval, documents, purchase history) and the list of accounting systems you need to exchange with — usually 1С, the warehouse and billing.
If you have exports of reference data, contracts and current approval regulations, the analysis will go faster: it is immediately clear where the data diverges and which fields will have to be reconciled manually.
In return we send back not general thoughts but a working package:
- Portal project estimate — by stage, with assumptions and explicit scope boundaries, so the scope does not "drift" along the way.
- Exchange scheme — which objects, in which direction and how often are synchronized between the portal and the accounting system.
- Stage-by-stage work plan — analysis and prototype, portal core development, integration, data migration, acceptance.
- Team composition — who handles analysis, who development, who integration and support, with a point of responsibility at each stage.
- Access and environment requirements — what is needed from your side: a test environment of the accounting system, accounts, exports of reference data.
- Risks and rollback points — what we do if the data does not reconcile or the launch needs to be postponed without losing what is already done.
The first analysis is one conversation; the estimate and stage plan follow within a few business days. Describe your task in free form: we'll come back with an estimate, exchange scheme and work plan, then we move through the stages on agreed timelines.