Choose the work the pilot needs to prove
An AI pilot needs a clear route into daily work. If the source documents are incomplete, the output has no agreed reviewer or staff have to change how they work without support, a useful demonstration can still fail to become a usable process.
Review three things before choosing the tool:
- The task: identify the question or output that causes repeated work.
- The sources: name the documents, records and people needed to complete it.
- The users: agree who will use the output and who will check it.
Use the review to decide whether the task is ready for a trial.
Make the cost of the current process visible
Record how the task is done today. Include time spent finding information, preparing the output and reviewing or correcting it. Record the volume of work and the exceptions that need experienced staff.
That baseline gives you something to compare with the trial. A faster first draft has limited value if the reviewer then spends longer checking it. Agree what a useful result looks like before the build starts.
Agree the scope in stages
1. Review the workflow and its sources
Choose a bounded task with an owner. Map the source material, access requirements and current process. Decide what the AI may prepare and which steps require approval. Implementation dates and commercial scope belong in the quotation after this review.
2. Build and test an agreed example
Use representative, approved material to test the workflow with the people who will use it. Check answer quality, missing information and the effort needed to review the output. Document the connections that are actually included.
STAX is an option to discuss when the task involves finding information in company knowledge and preparing a next step. Its knowledge layer and conversational layer are described on the product page. Custom integrations and actions need their own agreed scope.
3. Decide what is ready for wider use
Compare the trial with the baseline. Check whether staff can use the process, whether the reviewer can catch errors and whether source ownership is clear. Record actual tool consumption as well as time and quality. Expand only the parts that meet the agreed acceptance checks.
What to measure
| Review area | Evidence to collect |
|---|---|
| Task completion | Preparation time, review time and corrections on comparable tasks. |
| Answer quality | Whether the answer matches the approved source and handles missing information clearly. |
| Adoption | Whether the intended team uses the process in normal work and knows when to seek help. |
| Operating responsibility | Who maintains sources, supports users and approves changes. |
Agree access, documentation and handover responsibilities in the proposal. Ownership of software, hosting and support should be explicit in the agreement.
MatrixC’s role
MatrixC can help scope the first workflow, review the proposed cloud implementation and plan team enablement. The product, data connections and acceptance checks need to fit the work being proposed.
Keep the team involved during the trial. Staff should understand the approved sources, the review step and the limits of the output before relying on it for customer or business decisions.
Bring one workflow to the review
Prepare a short description of the task, its owner, the source documents and the output you need. Include the current review effort and the mistakes that matter. Use the STAX product page to discuss whether its organisation-level model fits that requirement.
For team learning, MatrixC Academy remains a separate route to review suitable training.
