By Artem Korsakov ·
An employee may request access setup, order supplies, or repair equipment. A manager forwards a message to a colleague. After a few days, it becomes unclear who took the task and what is missing for its completion. Employee requests in a unified registry help restore accountability and define the next step.
Select one category of inquiries
Different requests involve different executors and rules. Equipment procurement may require managerial approval, while replacing consumables is usually simpler. If you combine everything into a single long workflow, even a routine request will start waiting for unnecessary approvals.
For the initial launch, select one stream: for example, office facility requests. Record who submits the request, who accepts it, and under what criteria the work is considered completed. Complex procurements, HR procedures, and IT access can be reviewed after testing the first version.
What fields are needed in the form
The form must provide the executor with sufficient information:
- type of request;
- description of the situation;
- location or object;
- desired deadline with justification;
- attachment, if it helps clarify the issue;
- author's contact information for clarifications.
If the employee is already logged into the system, asking for their name again is usually unnecessary. However, contact details and department affiliation should come from a verified source. They cannot be considered reliable simply because they are written in a free-text field.
Decide in advance what to do with a request that lacks necessary information. The status "Needs clarification" and the executor's comment help continue the same process without creating a new card.
Separate execution and approval
The person responsible for execution and the person approving expenses may be different employees. The card must distinguish between these roles. Otherwise, the phrase "request approved" will be mistakenly perceived as "work completed".
A simple workflow might look like this: "Received", "Clarification", "Accepted", "In Progress", "Completed". For tasks involving expenses, add a separate decision by the approver. How to choose a tool specifically for this stage is discussed in the article on request approval.
Подпись: Illustrative example. The approver approves the expense, while the executor is responsible for the result. Therefore, "approved" and "completed" are stored in separate fields.
The history shows the author of the change, time, and comment. The history is accessible only to employees with the appropriate role; it is not visible to the rest of the company.
What to assign to the system
In a basic version, you can automatically set the date, assign a responsible party based on the selected category, and display requests that have not changed status for a long time. These actions are performed according to rules.
AI is needed only for specific tasks. For example, an employee writes a free-text description, and the assistant suggests a category. Confirming the category at the start is best left to a human. For full-scale tracking, AI is not mandatory.
First, check the capabilities of your existing CRM or task tracker. If the team already uses suitable tools, separate development is justified only by a specific inconvenience: an external form, a special workflow, or the required interface.
How not to turn the registry into another chat
Agree on where the official request number appears. If an employee writes in a chat, they need a clear transition to the card, and the executor needs a link to the original message. Correspondence may continue, but decisions and results must end up in one place.
Merge similar requests while preserving authors. For example, three employees reported a broken printer. The executor links them to one issue, yet each author receives the result for their own request. AI may suggest a match by object and description; the decision to merge is confirmed by a human. Similar text alone does not prove that the same device broke.
Подпись: Illustrative example. AI suggests a link by location and description; the executor verifies the device. Each author receives the result for their own request.
Bitrix24 (a CRM and collaboration platform) Smart Processes support custom fields and stages. This is one option for hosting the registry. Before development, check your tariff, permissions, and ease of use for employees submitting requests.
Rules for pending and cancelled requests
For the status "Needs clarification," a specific question, recipient, and date for the next action are required. Waiting for the author and waiting for the executor should be visible separately: they have different reasons and different responsible parties.
Cancellation preserves the reason. Reopening preserves the previous result and starts a new work stage in the same history. Overdue status is calculated according to an agreed calendar, considering only pauses that are actually provided for by the process. Otherwise, the report looks neat, but wait times are hidden behind the "clarifying" status.
Conduct acceptance testing on a regular request, a duplicate, a cancellation, and a request without an author's response. The manager must be able to find each situation and understand the next action. For a pilot, one department and one category are sufficient: this will allow you to check work discipline before adding new workflows.
How to accept the first version
Go through a request as an author, executor, and manager. Check cancellation, change of responsible party, and resubmission. The author must retain a card with a clear result. A notification sending error should not destroy the request itself.
To evaluate the result, count how many requests remain without a responsible party and how often the author had to clarify the status outside the system. Comparison is only useful with identical accounting rules.
trike_dev can break down one stream of internal requests and propose the composition of the first version. For discussion, an approval example and a request portal are suitable.
Related reading: Technical specification for automation: what to describe to the client; Data exchange between systems: how not to lose requests during failures.
Частые вопросы ### Is it necessary to migrate all old requests?
No. You can start with new requests, and transfer open old ones separately after agreeing on the data composition.
Can we keep the familiar chat?
Yes, as an additional communication channel. It is important to determine where the final card is stored and which action constitutes an official status change.