The least useful way to "introduce AI" is to pick a well-known product and then look for a job to give it. The tool is the last choice. The first choice is a task you can describe, a result you can count, and a person who remains responsible when the output is wrong. Four weeks is long enough to learn that on one workflow. It is not a promise that every firm should finish a rollout on day 30, and it is not a claim that AI belongs in every process.
A messy export, a contract review or a nervous director can stretch a week. The value of the sequence is the order. Uses that often fit a first trial, such as repeat questions, documents and internal search, are listed in seven practical uses of AI in business software. This piece is how to test one of them without skipping the measurement.
Week 1: identify the task and write down the baseline
Choose work that is repetitive, slow or easy to get wrong, and small enough that one team owns it. Good candidates include sorting incoming enquiries, pulling fields out of supplier documents, drafting a first answer from pages you already publish, or finding a policy in a folder of current documents. A poor candidate is anything that sends money, changes a booking or emails a customer with no one reading it.
Write the outcome in the language of the business. "Enquiry summaries that a coordinator can act on before calling" is an outcome. "Use AI" is not. Then record a baseline from the current process: time per item, how long a batch waits, how often a field is wrong, or how often a colleague has to ask for the source again. A fortnight of ordinary work is enough. Do not invent a target percentage. You need the "before", taken from your own desk.
Only then ask whether a model is required. If the inputs are already tidy and the rule never changes, a form, a filter or a simple automation will be easier to trust. AI earns the pilot when the input is messy and a person can still accept, edit or reject the result. AI development here means that bounded job, not a new department.
Week 2: look at the data, the risk and the tool
A model repeats what it can see. If the folder mixes current prices with last year's drafts, the answer will too. List the sources the pilot may use, and leave everything else out. Note which items are personal data, which are commercially sensitive, and which a contract says you must not upload to a third party.
Where the material identifies a customer, a member of staff or a supplier, UK GDPR applies, whether a person or a tool opens the file. Check the purpose, who can access the system, how long material is kept, and what the contract with a supplier allows. The Information Commissioner's Office guidance on AI and data protection is the public starting point. The ICO marks that guidance as under review following the Data (Use and Access) Act, so read the current page rather than relying on a summary. On accountability, the ICO says that in the vast majority of cases the use of AI is likely to be high-risk processing and therefore to require a data protection impact assessment, while also saying you assess that case by case and document the conclusion if you decide a particular use is not high risk. This article is not legal advice, and it cannot tell you that a given pilot is compliant.
Choose the smallest tool that can attempt the task. A general chatbot, an assistant inside software you already run, and a feature built into your own system are different levels of access. Prefer the one that can be limited to the sources you named. Write down what it must not be able to do.
Week 3: run a narrow pilot
Define the inputs and the outputs before you look at a single impressive demo. An enquiry classifier might accept a message and return a service, a location and a suggested owner. A document trial might return five fields and a link to the page they came from. If you cannot say what a wrong answer looks like, you cannot tell whether the pilot worked.
Agree the checks in advance. For anything that affects a customer, a member of staff or a price, a person reviews the result before it is sent or saved. Try the boring failures on purpose: a blank email, a document in the wrong format, two customers with similar names, a question the source pages do not answer. The model can state a plausible fact that is not in your material. That is a hallucination, and a tidy paragraph does not prove it is absent. The review step exists because of it.
Keep the old process available. If the pilot misfiles a morning's enquiries, the team should be able to go back to the previous method the same day, without a project meeting. Separate the trial data from live customer action until that fallback has been used once in practice.
A chatbot, an assisted workflow, or a deeper integration
A chatbot holds a conversation. It is a fair trial for repeated questions, provided it answers from your pages and refuses what those pages do not say. An assisted workflow stays inside work a person already does: it drafts, labels or extracts, and the person remains the one who finishes the task. A deeper integration reads and writes records in your systems, under permissions you set. That last kind can remove retyping. It can also write a wrong value into a live record, which is why it should not be the first week of a first pilot. The security questions that follow once a system can act across tools are discussed in agentic AI and governance.
Week 4: compare, then scale, narrow or stop
Put the pilot next to the baseline. Did the same work take less time once review is included, or did staff spend the saved minutes correcting the draft? How often was the output acceptable without a rewrite? What did the people using it actually say, including the complaints? Write the limits down: which inputs failed, which sources were missing, which actions still need a person.
Three decisions are all legitimate. Scale, if the result is good enough on the narrow task and the access can stay as tight as it was. Refine, if one change to the sources or the instructions would fix a repeated error. Stop, if the review takes as long as the original work, or if the data and the contracts will not support it. Stopping is a successful use of the month. Widening the tool because a vendor roadmap looks busy is not.
If you continue, keep a light record: what the system is allowed to see, who reviews it, and a date to look again when the source pages change. Maintenance applies here as much as it does to a website. A pilot that was accurate in spring can drift when the services you sell in autumn are different.
What this month does not prove
It does not prove a productivity gain for the whole company. It does not make AI appropriate for a process that needs a stable rule and a clean form. It does not replace a conversation with the ICO's current guidance, or with your own contracts, where personal or confidential data is involved. It does prove whether one named task is a candidate for a careful next step.
That next step, when it is justified, is usually a feature inside software you control, with the same boundary the pilot used. Business software is where the review screen, the log and the fallback should live if the trial moves beyond a standalone assistant.
Start with the task, not the product
Web Works Rise is a UK-led team in Birmingham, with a development hub in Tunisia for delivery. If you have a process that is repetitive enough to measure and bounded enough to review, contact the team and describe the task, the data it touches and what a person must still approve. A pilot shaped around that task is the useful version of AI work. A tool chosen first is not.