In a hypothetical team, a salesperson asks in chat, “Can we give a discount?” The manager replies, “Yes.” A week later, they discover they were discussing different orders. The messages survived; clarity did not.
Approval automation starts with describing the decision.
Give the approver enough information
A request should include the customer, proposal contents, normal price, requested change and reason. The company decides the exact list. The approver must see the precise version of the terms being submitted.
Bitrix24 supports approval workflows. Sequential and status-based approaches are described in the official guide. Check the required actions and plan availability in your portal.
Map three outcomes
Before configuration, describe approval, rejection and return for revision. Add another question: what happens if the approver is absent?
- Who decides, and who substitutes for them?
- When is a reminder needed?
- How does the salesperson learn the outcome?
- What happens if the amount changes after approval?
The last point matters especially. Approval of an older proposal must not silently become permission for new terms. Document the reapproval rule and test its implementation separately.
Accept the workflow through scenarios
Test an ordinary request, rejection, correction and an absent participant. Check using both salesperson and manager roles so each sees the appropriate information.
Acceptance should include a clear decision history: what was approved, by whom and against which version. Do not assume one template automatically covers every business exception.
Prepare a few typical discount requests and discuss a Bitrix24 process audit with QQDev. Clear rules before configuration mean the automation spends less time acting as a relationship counsellor between salespeople and their manager.