By Artem Korsakov ·
In short: an automation brief should describe the task, the participants, the data and the expected behaviour of the process. The client benefits from preparing real examples and decision rules. How the connection works and other technical details are clarified by the contractor after checking the systems.
The phrase “we need a convenient portal” sets a direction but does not explain what work it should support. For an estimate, it is more useful to describe what happens to a request from arrival to completion and who makes decisions along the way.
Prepare a description of the business process
Consider a hypothetical internal request to purchase equipment. An employee describes the need, a manager makes the decision, a assignee reports the result. For the first version, you can limit yourself to this route and a separate list of possible exceptions.
Explain what is inconvenient now: the status is unknown, information has to be repeated or comments get lost. Then describe what a finished result should look like for the author and the assignee.
If the goal is formulated as a specific change in work, it is easier to separate the necessary functions from wishes for the future.
Prepare answers to seven questions
- Who starts the process, and where?
- What information comes in at the input?
- Who checks the data and makes the decision?
- What stages does the task go through?
- What counts as completion?
- Where should the result be passed?
- What happens on an error or exception?
Attach anonymised examples to the answers: a successful request, an incomplete one, a cancelled one and one that needs rework. They help reveal rules that are hard to remember in a general discussion.
Screenshots of existing tools are useful as an illustration but do not replace a description of the expected action.
Separate roles and access
State that the author sees their own requests, the approver makes decisions within their area, and the assignee changes the working status. Separately decide who can appoint a deputy and close a request created by mistake.
Do not stop at role names. For each, list the visible records and allowed actions. The general approach is described in the article on access in a portal.
When files are shared, you need to define who sees attachments and whether access remains after the work is finished.
Describe the data and the boundaries of the connection
Each exchange needs a source, a receiving system and a set of data. The words “CRM integration” can mean creating one card, updating statuses or a full two-way exchange. These are different scopes.
Record whether migration of history, setting up notifications and work with non-standard objects are included. If AI is required, state what draft it prepares and who confirms the result. Having a model does not automatically solve the question of access to working data.
Remaining unknowns are marked as questions for discovery. They must not be silently turned into already agreed functions.
Training example for a register of facilities requests, showing how to turn general wishes into verifiable requirements: on one side, wordings that cannot be checked at acceptance; on the other, requirements that can.
Agree on acceptance criteria
Each important action needs an example check. For example: after a request is created, it appears for the person responsible; after a rejection, the author sees the reason; resubmitting does not create a second identical request.
Add situations where the external system does not respond and where permissions are insufficient. The contractor must understand the expected reaction, and the client must be able to check it without reading code.
It is useful to list further ideas separately. They will be kept but will not quietly expand the first estimate.
An example brief that can already be discussed
“We need a register of facilities requests for one office. An employee states the problem and the room, the administrator assigns a assignee, the author sees the result. A request without a room stays pending clarification. Pressing ‘Submit’ again does not create a second copy. The first version has no purchasing, payments or archive migration.”
To this description, add the existing system, available export methods and three real anonymised examples. If you want AI, phrase it separately: “suggest a category from the text, show the source, let the administrator confirm.” This way the model's function becomes a verifiable part of the process.
The capabilities of ready-made platforms are worth finding out before the estimate. Many accounting and ERP systems offer REST APIs, but for the brief, the specific installation, available data and the person responsible for maintaining it matter more. The contractor checks these conditions before promising a connection.
AI can help prepare the brief itself: from agreed interview notes, assemble a draft of participants, stages and open questions. Each rule should link to the original note. The process owner checks what was actually agreed, corrects the conclusions and approves the scenarios. Conditions that were not discussed remain questions.
Training example: AI assembles a draft of rules from interview notes. Each rule in the draft links to a note. The process owner corrects the conclusions, and anything unclear goes to the list of questions.
Where to keep open questions and changes
Each unknown should have an owner and an impact on the estimate. “It is not yet known whether the status can be obtained from the CRM” means the integration is not yet confirmed. In a prototype, it can be shown on training data, but this screen must not be passed off as a finished exchange.
When the brief changes, record the new rule and the affected check. For example, adding a deputy changes access and notifications, and a requirement to work offline changes the saving scenario. One short request can affect several parts of the product.
At acceptance, use the same examples on which the work was agreed, plus separate cases that were not analysed in advance. The result: the client goes through their process and sees all the expected decisions. They do not have to check the internal structure of the system to understand whether the product matches the agreement.
Who prepares the final document
The process owner confirms the business rules. The contractor clarifies technical capabilities, limitations and the method of checking. This is joint work: the client is not required to choose the database structure or the way requests are transmitted in advance.
At trike_dev, you can come with a description of one process and examples. See request approvals or integration. Before implementation, the logic is worth testing on a prototype.
Related reading: Preparing data for automation: reference data without confusion; Implementing AI in business: how to test one task in a pilot.
Частые вопросы ### Is a large specification required before the first conversation?
No. To begin, a description of the process, participants and examples is enough. The full set of requirements is formed after the task has been clarified.
Do you need to describe every button?
It is more important to define actions, data and the expected result. Interface details are refined on the prototype while keeping the agreed working logic.