CLIENT / CRM / Automation
Bitrix24 for B2C sales: orders, payment, delivery and the manager’s next actions.
From enquiry to delivery
Assigned ownerThe company already had Bitrix24. It needed a dedicated B2C path from qualification through delivery, receipt and payment reconciliation.
We refined an existing Bitrix24 setup for B2C sales: order records, required data, stage activities and next-action deadlines.
A dedicated B2C sales pipeline in Bitrix24.
Enquiry, order, payment and delivery in one process.
From enquiry to delivery
Assigned ownerKey information and the next action stay together.
The complete order context
Assigned ownerThe owner and deadline stay with the order.
Delays call for a manager or supervisor to act.
A delay needs an action
Deadline controlThe delay is highlighted in the workflow.
The manager records the contact result and next action. Order confirmation requires payment and delivery methods, with separate shipping and receipt data. The manager reconciles payment manually; successful closure checks payment confirmation and a positive amount.
Testing revealed that changing the next deadline in the deal did not update the existing activity. We built a separate synchronisation service and tested deadline changes on a technical deal. Four older delayed notifications were disabled when switching to that service.
A technical deal passed through the workflow to completion, including required-field checks and a return when payment was unconfirmed. Wazzup messages were configured for order agreement, delivery, collection and review requests. Testing every messaging branch and confirming staff adoption remain separate checks.
B2C V1, required data and stage activities were configured. Transitions and payment checks were tested on a technical deal; a separate service was tested for activity deadline changes.
Bitrix24 captures from 19 October 2026. They show test deals and configuration without customer personal data.
The archive establishes early V1 and later refinements. BYstudio did not build a website for Krest-NN. Messages were configured in the existing Wazzup setup; not every branch or the three-day review-request delay has been independently verified.
Bitrix24 already existed. This comparison covers early V1, prepared within this project, and its 16-17 October 2026 refinement. It reconstructs configuration from archived evidence, rather than measuring team performance.
A stage and a first-activity rule with a 15-minute deadline exist. Execution in early V1 is unverified.
The stage exists. No automation was found on this stage in the 7 October check.
Order fields exist. Payment and delivery options are not yet populated.
A stage and logistics fields exist. No automatic stage activity was found in the archive.
The stage and successful ending exist. An enforced closure condition in early V1 is unverified.
Initial activity, 15 working minutes and escalation. Progress requires a contact result and the next deadline.
An agreement activity is created. A separate service synchronises the open activity when its next deadline changes.
Payment and delivery methods are required. A shipping preparation activity is created and an order message is enabled in Wazzup.
A receipt-control activity, shipping data and separate carrier and collection messages. The manager supplies the tracking number.
The manager reconciles payment manually. Without confirmed payment or with a non-positive amount, the deal returns for checking.
Basis: archived stages and fields, configuration logs and technical checks, reviewed on 19 October 2026. The complete pre-project process, staff adoption and measured sales impact are not established.
The initial task discussion is free. Describe it in your own words. A BYstudio specialist or Yan Bunin will respond.