Start with a recurring activity
Before choosing an AI tool, observe a normal working day. Where does the team copy the same information? Which messages need reading before they reach the right person? Which answers keep sending you back to the same documents? These observations offer a more useful starting point than a list of impressive features.
Choose an activity with a clear start and finish. For example, a website enquiry must become a complete record for the colleague preparing the quote. Note the time spent, frequently missing information and how a correct result is recognised. If the process varies between people, clarify the working rules first.
Where AI helps and where rules are enough
A notification sent after a form submission or a price calculation based on a rate table usually does not need an AI model. Interpreting a free-text message, however, may benefit from one. We recommend keeping explicit rules for predictable steps and using AI where variable content needs understanding.
This choice aligns with Anthropic's distinction between workflows with predefined steps and agents that choose their actions dynamically. Greater autonomy brings trade-offs in cost, duration and control. For a first project, a bounded workflow is easier to evaluate than an assistant with access to every company system.
Three examples to start with
Quote requests: a proposed system can extract the project type, desired deadline and remaining questions from a message, then prepare a record for the team. If no budget is mentioned, that field stays empty. A colleague checks the quote and commercial commitments before they reach the client.
Incoming documents: automation can suggest a file category and the data needed in your internal application. Design a review queue for unreadable documents or conflicting information. Keep a link to the original document so verification is quick.
Recurring questions: an assistant can draft replies using approved company documentation. Define the covered topics and situations requiring human takeover from the start. These are design examples, not promises that any model or integration will work correctly without testing.
Design for incorrect answers too
For quote requests, we would separate message interpretation from actually sending the quote. The team sees extracted information beside its source, can correct the record and approves the next step. Convincing wording from a model does not prove the data is correct.
Decide who can see the information, what goes to the AI provider and how long you keep the history needed for review. Grant access only to systems required by the process. For actions that modify data, include validation, duplicate-execution protection and a rollback path. If the service does not respond, the request must remain available for manual processing.
Measure time saved after review
Prepare representative examples: complete messages, vague requests, unusual documents and cases that should not be processed automatically. Use appropriate test data and compare results with verified answers. Record omissions, invented details and the time needed to correct them.
An illustrative calculation: with 100 enquiries per month, reducing hands-on work from 8 to 3 minutes would save 500 minutes. Those 3 minutes must include review and correction, and this is not a result achieved by Verosea. Compare the value of that time with implementation, service usage and maintenance costs.
A pilot is useful even when it shows that a process is not worth automating yet. The volume may be too low, or review may take as long as the original work. In that case, improving the form or data organisation may be a better investment.
What a well-defined first project looks like
Bring an example enquiry, the steps it goes through and the result you expect to our first conversation. We can outline an integration around the website, CRM or application you already use, with a person responsible for review and acceptance criteria agreed before implementation.
The goal is a process the team understands and can use every day. Expanding to other activities makes sense once the first workflow proves it saves effort and its exceptions can be managed.