Start with a recurring decision or task that your team can describe and measure. Buying a model subscription does not establish whether the company has the right data, permissions or working practices to use it effectively.
A useful first project has a named owner, a bounded task and a reliable way to identify mistakes. Drafting an answer for an employee to check is a different proposition from allowing a system to approve payments or reject applicants.
Choose a task with a measurable baseline
Observe how work happens, including exceptions. Record the number of cases, active handling time, waiting time, corrections and the people involved. A slow process may need a clearer rule or a system integration rather than AI.
| Candidate | What AI could help with | What the pilot must test |
|---|---|---|
| Incoming enquiries | Suggest a category and route | Misrouting, uncertain cases and reassignment |
| Internal document search | Retrieve sources and draft an answer | Correct sources, access permissions and unanswered questions |
| Invoice capture | Propose fields from documents | Field accuracy, duplicates and review effort |
| Proposal preparation | Draft from approved information | Factual accuracy, pricing approval and editing time |
Select a task whose output someone can assess. If nobody can explain what a correct answer looks like, define the process before choosing the tool.
Separate data preparation from model choice
Find the authoritative source for each answer or field. Remove obsolete duplicates, establish ownership and decide how updates reach the system. Test whether different employees should see different records.
For document questions, retrieval-augmented generation can supply relevant passages to a model. It does not automatically fix contradictory documentation or guarantee accurate answers. Read the RAG guide before treating a knowledge base as a complete solution.
A model also needs boundaries: permitted inputs, permitted actions and a route to human review. Credentials and approvals belong in the application and its access controls, not in a promise inside the prompt.
Run a bounded pilot
Prepare representative examples before configuration, including missing data, unusual documents and questions that should be refused. Keep a separate evaluation set that has not been used to tune the system.
- Agree on the task, owner, risks and acceptance criteria.
- Establish the baseline using the current process.
- Test with suitable data in a controlled environment.
- Compare results and review effort with the baseline.
- Decide whether to stop, revise the scope or deploy.
The schedule depends on data access, integrations and the consequences of failure. A demonstration that answers a few selected questions is not evidence that the same system can handle the company’s full workload.
Build a business case using explicit assumptions
The following is an illustrative calculation, not a QA10 result or quotation. Suppose 500 invoices take six minutes each to process: 50 hours per month. At an assumed labour value of PLN 55 per hour, that is PLN 2,750.
Assume a pilot shows that the remaining review takes ten hours per month, and the tool costs PLN 300 monthly. The new operating cost in this simplified model is PLN 850, leaving a monthly difference of PLN 1,900. Over twelve months, that is PLN 22,800 before the initial investment.
With an assumed implementation cost of PLN 18,000, the simplified first-year ROI is:
(22,800 − 18,000) ÷ 18,000 × 100 = 26.7%.
This calculation excludes tax, discounting, ramp-up, additional integrations and changes in workload. Released employee time is capacity, not automatically cash saved. Count it as a financial benefit only when you can explain how it reduces spending or produces useful additional output. Include ongoing review, support and maintenance in the real model.
Assign ownership before deployment
Someone must maintain source content, review incidents, approve changes and watch costs. Record which model and configuration produced an answer, within your data-handling rules. Test again after a model, prompt, document collection or integration changes.
Choose a ready-made tool when it meets the workflow and access requirements. Consider custom software when the process needs integrations, controls or behaviour that available tools cannot provide. Supplier prices and licence conditions should be checked for the actual configuration.
Questions before starting
Do we need our own model?
Not necessarily. Start by testing whether an existing model or application can meet the task, access and quality requirements. Fine-tuning is a separate choice that requires suitable data and evaluation.
How do we know whether the pilot worked?
Compare accepted outputs, review effort, errors and operating cost with the same measures from the original process. Agree on those measures before the pilot starts.
Turn the findings into a next step
For a programme starting with company processes and AI adoption, Q-Journey includes the AiP audit within the wider journey. Express and Platinum address different scopes; Platinum also includes Lean and Muda consulting. Scope and timing are agreed for the project. When the required software is already defined, Q-Dev is the appropriate starting point.