Notes / Workers
How to Use AI in Your Business and Measure Its Value
A proposal workflow shows where AI may help, which decisions belong to people, and what to measure before calling the change a business improvement.
Watch on Loom · 10 min 19 secBy Edu Rigonato. Published Oct 29, 2026. 10 min read.
A proposal can be quick to write and slow to finish. The meeting notes are ready, but someone still needs to confirm the scope. The estimate is waiting on a colleague. A question from the prospect sits in an inbox. Producing another draft does little for those delays.
In the accompanying video, I walk through the people, tools and decisions involved in preparing a proposal. AI may help with parts of that work, but the useful starting question is what needs to improve from beginning to end.
Start with a recurring job connected to a business result. Map how it gets done, compare AI with simpler ways to improve it, and test whether acceptable finished work takes less total effort. Count the checking, corrections and ongoing costs. Then look at what the improvement makes possible: lower expense, better service, more usable capacity, or additional revenue you can actually attribute to the change.
Which business result needs to improve?
Before choosing a tool, name the problem in terms your team can recognize. Perhaps quotes arrive too late. Staff repeatedly fix incomplete records. A manager spends afternoons collecting information that already exists somewhere in the business.
“Use more AI” does not tell you which of those problems deserves attention. A useful objective might be to get complete proposals ready for review sooner, reduce time spent correcting them, or let the same team handle more qualified opportunities without lowering standards.
Each objective needs its own evidence. Shorter turnaround is a time measure. Fewer corrections concern quality and effort. Extra capacity means people have time and attention available for useful work. None tells you, by itself, how much revenue increased or expense disappeared.
Research shows that AI can improve a defined job. A published study of 5,172 customer-support agents found a 15% average increase in issues resolved per hour after AI assistance was introduced. The gains varied by worker experience and skill. That was one company’s support operation using earlier technology; it is evidence for that setting, not a target to put into your own business case.
In the video, I compare routine email handling with work closer to generating and serving business opportunities. That reflects priorities in my own business. If unanswered email is where your customers get stuck, it may deserve attention. The point is to locate the constraint in your business rather than assume the most visible task is the most valuable one to change.
Ask the person who does the work where it stalls, and the person who receives it what usually needs fixing. Those answers can be more useful than a list of features.
Where does proposal work lose time or momentum?
In the agency example, a prospect conversation starts the proposal process. Getting to a useful proposal requires more than turning notes into polished sentences. Someone has to understand the request, identify the work involved, estimate the effort, resolve questions and confirm what the agency is prepared to deliver.
Trace a recent example through the people and tools involved:
1. Gather the requirements. What came from the meeting, email and existing records? What is missing or contradictory?
2. Define the work. Which deliverables belong in scope, and which need a separate decision?
3. Prepare the estimate. Who supplies effort, availability, pricing and assumptions?
4. Draft and review. Can the person checking the proposal trace its claims and commitments to approved information?
5. Prepare follow-through. Who owns the next step, and what happens if a question or approval is overdue?
Keep the waiting visible. A proposal that takes an hour to prepare but spends three days waiting for a decision has two different problems. Better drafting may help with one. It will not resolve the other unless the workflow also brings the right question to the right person.
This mapping approach is consistent with OpenAI’s small-business workflow workbook: identify inputs, steps, outputs and places where human judgment matters before choosing what to delegate. It is practical vendor guidance, not proof of a particular return.
The video also discusses opportunities falling through gaps when several proposals are in progress. Treat that as a reason to examine ownership and follow-through. An opportunity’s quoted value is not revenue already earned, and it is not money an AI system can claim to have recovered. Winning the work, delivering it and earning an acceptable margin are separate outcomes.
You should finish the map able to point to a specific delay, repeated effort or quality problem. If all you have is a diagram of the software your business uses, ask where the work actually gets stuck.
Which steps need AI, and which have a simpler solution?
Some improvements may require no AI at all. A shared proposal template can remove repeated formatting. A required field can catch missing information. An existing task reminder may make an overdue approval visible. A fixed rule may route a complete request to the right person.
AI becomes a candidate when the work involves variable language or information that needs interpretation—for example, preparing a requirements summary from a meeting and several emails. Even then, ask whether the result can be checked and whether the inputs contain what the system needs to know.
Anthropic’s engineering guidance recommends starting with the simplest adequate implementation. It distinguishes workflows with predefined steps from agents that choose how to proceed. Extra flexibility can bring extra cost, delay and opportunities for error. An agent is a design choice to justify, not a requirement for getting useful work done.
For the proposal example, you might use a template for the document, existing software for reminders, AI to prepare a summary, and people to approve scope and pricing. The combination matters more than how much of it carries an AI label.
Ask whoever will implement the improvement to explain why each part is needed, what it costs to run and how it behaves when information is missing. Your responsibility is to judge whether the proposed approach serves the business; you do not need to become the person configuring every connection.
If you need help defining the job itself, our guide to an AI Worker’s initial responsibilities and scope goes further into that decision. A Worker can carry connected responsibilities. Testing one part first simply gives you a manageable place to learn.
Which decisions should stay with your team?
A proposal creates commitments. Someone with authority needs to decide what your business will deliver, at what price, under which assumptions and on what schedule. Preparing information for that decision is different from making the commitment.
An unusual photography request, mentioned in the video, illustrates an exception. The workflow may be able to flag the request and collect relevant information. It should have a defined route back to a person who can decide whether the agency offers the service, needs a partner or should change the scope.
Make the review practical. Name the person who checks the proposal, the information they need, and the decisions that cannot proceed without them. For a scope review, that might mean checking the proposed deliverables against the prospect’s request and confirming exclusions. For pricing, it may mean verifying the approved estimate rather than accepting a number that appeared in a draft.
An approval button is useful only if the person has the context, time and authority to reject or correct the work. NIST’s AI Risk Management Framework places human oversight within the intended use, costs and consequences of a system. It does not make the presence of a reviewer a guarantee of correctness.
For the proposal workflow described here, the team retains control of client commitments and final delivery. The system can prepare a proposal or follow-up draft and bring it to the responsible person. Missing information, an unusual request or a disputed assumption should be visible at that handoff.
Agree who will handle those exceptions before the work begins. Otherwise, the apparent improvement may be a new queue of questions nobody owns.
Did the workflow improve, or just the first draft?
Establish a baseline before introducing the change. For a representative set of recent proposals, record the time spent gathering information, drafting, checking, correcting and resolving exceptions. Also record the elapsed time from a complete request to an approved proposal. Staff effort and customer waiting are different measures, and both can matter.
Use the same acceptance standard when reviewing the test. A proposal is not complete merely because a file exists. It needs the required information, correct scope and pricing, and the approvals your team expects.
Keep the review focused on a few questions:
- Are more proposals reaching the agreed standard, or reaching it sooner?
- How much time does your team spend on the entire job, including corrections and exceptions?
- What does the system cost to set up, run, maintain and supervise?
- Where does any freed time go, and does that use help the business?
For example, use a test proposal where the source notes explicitly exclude photography. Check whether the draft preserves that exclusion and whether the reviewer can verify it quickly. If the reviewer has to reread every email and rebuild the scope, record that effort before counting the draft as a time saving.
A published experiment with consultants found that AI helped on selected tasks but reduced correctness on a different task. That is a reason to check the work your process actually contains, rather than judge the whole system by its best-looking output.
Perceived speed also deserves scrutiny. In METR’s early-2025 trial, experienced developers working in familiar repositories believed AI had helped them finish faster, while measured completion took longer. This was a small, specialized study using tools of that period. METR’s later update says newer effects are difficult to estimate reliably and considers greater speedup likely. Neither result tells you how today’s proposal workflow will perform; both reinforce the need to measure it.
Keep the financial interpretation equally clear. Time returned to an employee creates capacity; it does not automatically reduce payroll. More proposals sent are not necessarily more good-fit projects won. To connect the change to revenue, track what happens to comparable opportunities and consider other changes in demand, pricing or sales activity. A small pilot may establish a useful operational improvement well before it can establish a revenue effect.
Record setup effort separately from recurring expense so both remain visible. Avoid counting the same benefit twice—for example, treating an hour as both a cash saving and capacity for extra work when no cash expense changed.
What would justify investing in the next step?
Choose a part of the mapped workflow that gives you a useful result to inspect. In the proposal example, that could be preparing a requirements summary and a list of unresolved questions for a person to review. You can test that without handing over pricing or client communications.
Agree what would make the test worth continuing. The summary might need to preserve required facts, distinguish open questions from confirmed information and reduce total preparation-and-review effort. Your team should also decide which errors are unacceptable and who can pause the work.
Include ordinary cases and awkward ones: a missing budget, conflicting dates, a changed request, an attachment that cannot be read. Ask the implementation team to show how each returns to a person rather than disappearing into a plausible answer. Anthropic’s evaluation guidance emphasizes clear success criteria and tests for behavior that should—and should not—occur.
After the test, the decision may be to expand, adjust the approach or stop. A result that saves drafting effort but creates expensive corrections may need a narrower role. A useful summary may justify trying the next step in the proposal process. You do not have to make that decision for the whole business at once.
Our guide to evaluating a Worker before live work covers the checks in more detail. For this first business decision, bring a recent example, identify the costly delay or repeated effort, and agree what the finished proposal must contain. Then test whether the change gets that proposal approved with less effort, better quality or a shorter wait. Use the results to decide whether to invest further.
Evidence note: This article combines the accompanying workflow walkthrough with linked research and operational guidance. The proposal workflow is an illustration, not a measured Taurist client result. The studies concern specific tasks, people and tool versions; vendor guidance informs the recommended process but does not establish a guaranteed return.
Frequently asked questions
What should I bring to a first workflow review?
Bring a recent example of the work, the information it started with, the finished output and the tools and people involved. Include something that went wrong or needed clarification. You do not need a polished process manual to begin; a concrete example helps reveal the missing steps.
How long should a first pilot run?
Long enough to observe the kinds of work and exceptions the system will encounter. A daily process and a monthly process need different observation periods. Agree on the work sample and acceptance criteria first, then choose a review date that gives your team enough evidence to make a decision.
What if our records are incomplete or the process changes each time?
Identify what must be known before work can proceed and how the person doing it currently finds that information. Better records or a clearer request form may be the first improvement. A test can also show whether the system reliably identifies missing information instead of filling the gaps with assumptions.
Should we continue if drafts are faster but corrections increase?
Compare the combined effort and final quality with your agreed standard. Review a few corrected examples with the person responsible for the work: missing context, unclear instructions and an unsuitable task call for different fixes. Narrow or stop the test if it cannot meet the standard at an acceptable cost.
Explore Workers