By Artem Korsakov ·
In short: Request approvals can be set up in a CRM if the participants already work in it and the system supports the required route: returns, delegation, notifications. A separate service is justified when external organizations take part in the process or the route differs greatly from what the CRM can do. In both cases, first describe what each decision is about and the rules for exceptions.
Automating request approvals requires rules for approvers being on leave, the amount changing and a request being sent back for correction. The choice of tool depends on these rules more than on how the form looks.
If your CRM lets you set up the required route transparently, you may not need a separate service. But first it is worth describing what counts as a decision and what consequences it triggers. An approve button without clear conditions just moves a disputed process into a new interface.
Define what is being decided
What does the person approve: the amount, the supplier, the timeline or the whole set of terms? Who can edit the request after approval? If important fields have changed, should the decision still stand? You need the answers to choose and configure any product.
In a hypothetical company, an employee requests an equipment purchase.
- The manager confirms the need.
- A finance employee checks the budget.
- Procurement chooses the supplier.
These are three different decisions. Combining them into one “approved” mark hides responsibility and makes delays harder to explain.
Describe what the request contains at the moment of decision and whether attachments are visible. The approver needs to understand which version they are reviewing. If a file was replaced later, the history should make it possible to reconstruct the circumstances. The specific depth of history is determined by risk and business needs.
When the existing CRM is more convenient
Configuring the CRM makes sense if the participants already work in the system, the necessary data is stored there and the available mechanisms support the route. Check returns, notifications and delegation on your plan. You should not treat any sales pipeline as a ready-made approval mechanism just because it has stages.
The benefit is that there is no separate user list and no re-entering information. But the process must remain clear: who makes the decision, who currently has the request and what is needed to move it forward. If employees have to discuss everything in chat and update statuses after the fact, the automation is serving the report for now, not helping the work.
When a separate service is justified
A separate solution is worth considering when external organizations take part in the process, special forms are needed or the route differs noticeably from what the current system can do. For example, a contractor sends a set of documents, an internal specialist returns comments, and the client sees only the approved result.
This brings new responsibilities: access, notifications, data storage and exchange with other tools. What makes up the cost of such an exchange is covered in the article on CRM integration. A custom service does not remove the need for rules. The general approach to choosing between a ready-made product and development is described in the article “Off-the-shelf service or custom development for your business”. If departments do not share an understanding of the approval procedure, development will only lock the dispute into software.
Check returns and exceptions
For each reason for rejection, define the next step. Returning a request for correction is different from a final rejection. The employee should see what to change and whether those who approved the previous version need to approve it again.
Decide in advance who stands in for an absent manager and who has the right to reassign a request. Urgency must not silently turn into bypassing all checks. If an exceptional decision is allowed, its grounds and author should be clear to participants.
Look at parallel reviews separately. Budget approval and document review can run at the same time, but the final action starts after both decisions. It is important to check that a rejection by one party does not get lost after a positive answer from the other.
Do not confuse the duration of a technical stage with the time a person takes to decide. An automatic reminder does not fix a lack of budget or authority. Monitoring requires reasons for a hold that participants can actually state. From them, a manager will see whether the system needs fixing or an organizational decision is required that cannot be replaced by yet another notification.
How to choose without major development
Take a few typical requests and run them through a practice process. Include:
- a change in the amount;
- an approver on leave;
- resubmission;
- a missing required document.
Compare how many actions the CRM requires and what a separate service would require.
To discuss this with trike_dev, prepare a sample request and a description of exceptions. The approvals demo will help you see the route, but the working data exchange and access rules need to be assessed and implemented for your task.
Частые вопросы ### Can we start with one department?
Yes, if the process boundaries allow you to test the decisions and the result separately.