The hidden work behind an AI pilot.
A promising pilot needs people who understand both the technology and the business process it is meant to improve.
A promising AI pilot can create a second job for the employee who started it. They test the tool on real tasks, compare what comes back, ask colleagues what is missing, and revise the process when it fails. The work can be valuable, but it still takes time alongside everything that employee was already responsible for. A two-year study of a medical center and a law firm describes how much experimentation and coordination sit behind AI solutions that become useful across an organization.
There is another kind of work hidden inside that pilot. Someone has to understand what the tools can do and how the business actually runs, then connect the two. That combination is hard to find in one person at a small company. Ruby fills the gap by learning the processes behind the team's most important measures and translating them into choices about the tools, information, and review the workflow needs. If a company already works in Claude, ChatGPT, or Copilot, we start there, find the workflow that is worth improving, and help the people involved make it part of their regular work.
The person closest to a process usually knows where it slows down. They know which information has to be checked before a customer gets an answer, which exceptions need an experienced employee, and which steps look simple until a request arrives in a different format. A person who understands AI may see that a tool can read a document or prepare a response, but without that business context they can easily automate the wrong part of the job.
That is why a useful pilot starts with two conversations at once. What business measure is this work meant to improve, and what actually happens between a request arriving and a result going out? The answer might point to a sales handoff, a delayed approval, or a repeated internal question. Once the team can describe the path, it can decide which steps a tool should assist, which information it needs, and where a person should review the result. The tool choice matters, but it should follow the process and the people who own it.
The researchers' working paper compares two organizations where employees were encouraged to experiment with AI. MIT Sloan's account describes how the effort to test, review, and maintain those solutions was supported differently. This was a study of one medical center and one law firm, not a prediction for a 30-person business. Still, it asks a question leaders should take seriously: who has the time and support to keep improving the pilot after the first version works?
At Ruby, our role is to translate between the people who know the work and the technical choices available in the software a team already has. That can mean documenting a process, identifying the highest-priority bottleneck, shaping a workflow around it, and helping employees learn where to trust the output and where to use their own judgment. We meet the team where it is and start with the tools and processes it uses today.
The goal is for a pilot to stop depending on one person's spare time. A company should be able to say what the workflow is for, who owns it, how the output is checked, and whether it is improving the measure that mattered in the first place. When the business and technical sides are connected in that way, the work has a better chance of lasting.
Sources & further reading
Start with the work. Build the right system around it.
We help teams understand where AI is useful, choose the right tools for the job, and build the confidence to keep improving.
Book a Call