Process selection, source data, and pilot evaluation before AI implementation.
Bringing artificial intelligence into a business starts with an operational task. Optimising a business does not require restructuring the whole company: it is easier to choose one process with a clear starting point, outcome and responsible employee. For example, an enquiry submitted through a form needs to be checked, entered into the working system and passed to a manager.
This is a hypothetical example. In your business, the first area might be drafting a document, gathering information from spreadsheets or reminding someone of the next action. The key is to describe the work so that, after the change, you can verify exactly what now happens differently.
Choose a process to optimise using five questions
If the company has several candidate processes, describe each on a single card. Compare specific operations, such as transferring an enquiry to CRM or preparing a proposal draft. The broad task of “implementing AI across the business” does not show which actions should change or who will accept the result.
- Frequency: how many similar cases occur in the selected period, and how much time does an employee spend on each completed case?
- Rules: which steps can be described by a precise condition, and where must free-form text be understood? Not every automation needs to be built on AI.
- Data: where does the information come from, who checks that it is current and which fields are most often missing?
- Control: which actions can the system perform independently, and what must an employee confirm?
- Recovery: how can you detect an error, find the affected record, and continue working manually?
A process with accessible source materials, a clear outcome, and someone responsible for acceptance is a good fit for a first pilot. Depending on the task, these individual guides may help: transferring enquiries to CRM without duplicates, a draft commercial proposal with AI or choosing a chatbot for enquiries. These scenarios can be connected later, once each transition has been tested.
Document the current process
Walk through one real cycle with the person who performs it. Where does the data come from? What does the employee copy, check and clarify? Where is the result stored? Who needs it next?
Do not limit testing to the ideal case. Record what happens when a phone number is missing, an enquiry is repeated or the description is unclear. These details help define the first launch and avoid hiding difficult cases behind the general phrase “move everything into the CRM”.
Define the input and output
Each stage needs specific information. The input may be a completed form, a spreadsheet row or a message. The output may be an enquiry record, a prepared draft or a notification to an employee.
Create a simple map:
- the event that starts processing;
- required fields;
- the source of correct values;
- the system action;
- the recipient of the result;
- how to correct an error.
If any point is still unknown, clarify it before choosing a tool. Sometimes working through this map reveals that part of the complexity can be resolved simply by clarifying the team’s rules.
Separate rules from AI tasks
Checking a required field or routing an enquiry by the selected category can follow a predefined rule. A language model is not always needed for this.
AI can be considered where free-form text needs interpreting, information must be found in agreed materials, or a draft answer is needed. It is important to define acceptable errors and how the result will be checked. For example, the system can suggest a request category, while an employee confirms a disputed choice.
Prepare examples and the expected outcome
Collect anonymised examples of routine and difficult cases: a completed enquiry, a request missing required data, a repeated message and contradictory information. Record the correct outcome or reason for handing over to a person for each. Specify the current source of facts and when it was checked: the model must not guess a missing price, deadline or company rule.
Separate configuration materials from an independent test set. If you configure and evaluate the system using the same successful examples, the results will be overly optimistic. Test cases should reflect the work the team actually receives, including exceptions.
A company in Kazakhstan should build its test set from real enquiries. If customers write in Russian and Kazakh, test both languages and mixed-language requests. Specify the phone, address, amount and currency formats used; ask an employee to check that transferring the data does not change its meaning. Do not add languages and integrations just to expand a feature list.
Complete a pilot before connecting the live workflow
- Document the existing process: who handles enquiries, how long preparation and checking take, and which errors need correcting.
- Describe a limited scenario, the available sources and the actions the system must not perform on its own.
- Test the prototype with prepared data. At this stage, the result remains a draft; emails, payments, and changes to working records are not carried out without the agreed confirmation.
- Run through the test cases with an employee: a successful result, missing data, an incorrect answer and an unavailable external service.
- Compare the results with the original process. Decide what to fix, whether to launch a limited live workflow and who will be responsible for monitoring it.
Before the pilot, agree on what counts as an acceptable result. Speed matters, but so do allowable errors, the amount of manual review, service costs, and the ability to keep working without automation. Set the threshold for the specific task rather than borrowing it from someone else's promotional case study.
- For a request: a missing required field triggers clarification; redelivery of the same inquiry creates no duplicate; a transfer failure remains visible to the responsible person.
- For a document: figures and terms match the stated sources, unverified information is marked, and an employee can return the draft for correction.
- For launch: test examples and the reviewer’s decisions are saved, an owner is assigned and the manual process is tested. Agree acceptable processing time and the proportion of corrections for this process before the trial.
Check integration capabilities
The name of a CRM or accounting system alone does not confirm that the required action is available. Its specific version, interfaces, permissions, and limits must be checked. It is important to distinguish in advance between reading data, creating records, and modifying existing information.
Also discuss the working environment: which data may be sent to the selected services, where it is processed and who manages access. These conditions shape the solution alongside its functions, service costs and ongoing support.
Provide a stop mechanism and a manual fallback
Imagine an external service did not respond or an inquiry is missing a required value. Should the system retry, send the record for review, or notify an employee? What will help establish whether the request has already been processed?
Human confirmation can be required for important changes. The responsible person should retain the ability to correct the result and continue manually. It is useful to test the recovery procedure alongside the main scenario before launch.
Compare the result using comparable examples
Before the change, record the number of manual actions, processing time and typical corrections. Then handle comparable enquiries using the new method. Measure not only the automated step’s speed but also the employee’s review time.
- Time to an accepted result: preparation, waiting, review and corrections combined. Compare similar tasks over a period chosen in advance.
- Quality: how many results were accepted without substantive edits and how many needed factual corrections or referral to a specialist.
- Reliability: omissions, duplicate records, failures and the time needed to restore the manual process.
- Costs: services, maintenance and employee review time. A quick draft does not mean savings if correcting it takes longer.
A simple log is useful for a request: example identifier, expected fields, actual result, reviewer's comment, time, and decision. An unknown effect is recorded as “not yet measured,” not as zero or positive. If the criteria are not met, the pilot is improved or stopped; an autonomous launch is not a mandatory outcome.
Calculate the impact using a clear example
A hypothetical example, not a GIFS project result: a company handles 200 similar inquiries a month. Previously, an employee spent an average of 12 minutes per completed inquiry. In the pilot, it takes 8 minutes, including review and corrections. The difference is (12 − 8) × 200 = 800 minutes, or 13 hours 20 minutes a month at the same volume and comparable quality.
Time saved does not automatically mean an equivalent financial saving or sales growth. Account separately for service fees, support, and one-off work; see how the team actually uses that time. If the new process makes more mistakes or requires additional review in other departments, include that work in the calculation. Do not apply an educational example's result to your company without measurements.
You can start the discussion with a few lines: “We get data here, perform these actions, and want this result.” In the section implementing AI in business describes the GIFS approach to these tasks. Send the sequence of steps, service names and an anonymised example — this provides a basis for defining the pilot’s scope and checking connections.