The Pilot Works Until The Workday Starts
Imagine an illustrative estimating team after an impressive AI demonstration. The assistant can turn an enquiry into a tidy brief. On Monday, the coordinator uses it, then copies the same information into the old spreadsheet because the estimator still expects that spreadsheet. The team has adopted a tool and added a task.
The problem is not necessarily reluctance to use AI. The operating agreement has not changed. People still answer to the old handoff, old measures, and old expectations. The new brief is an extra artifact that nobody has clearly agreed to accept.
Before expanding the pilot, I would ask each role a concrete question: what will you do differently on the next real enquiry? Then I would ask the manager which existing activity will stop once the replacement has been validated. Both answers belong in the implementation.
Describe Behavior At The Handoff
For this proposed pilot, the coordinator would capture the enquiry once, check the prepared brief, and resolve missing intake facts. The estimator would accept that brief in the agreed record or return it with a specific reason. The manager would monitor unresolved handoffs and remove conflicting requirements.
These are observable actions. They are easier to discuss than broad requests to trust AI, become innovative, or use more prompts. Staff can explain whether the behavior fits the actual job and identify where the proposed process would create trouble.
The agreement should also define what does not change. The estimator still makes the estimating judgment. The coordinator still owns incomplete intake. The manager still decides when the old duplicate process can be retired. Clear responsibilities give people a way to use the new workflow without guessing what accountability moved to the assistant.
Measure The Extra Work Before Promising Savings
Suppose, illustratively, the team receives 50 enquiries weekly and spends seven minutes entering each into two places. That is 350 minutes. If a single intake record and reviewed brief require four minutes per enquiry, the gross difference is 150 minutes.
If training, support, and exception handling consume 90 additional minutes during the measured week, the net capacity difference under those assumptions is 60 minutes. An early week may even require more effort than the old process. Reporting that honestly helps the team distinguish learning costs from persistent design problems.
Time released is not the same as cash saved. It may allow the coordinator to handle the same queue with less pressure or respond sooner. The business must decide how to use that capacity and measure whether the intended benefit actually appears in completed work.
A SynHy Proposal Around One Accepted Brief
We could build a focused intake assistant for one enquiry type. AI would organize the customer's wording into an agreed brief and identify likely missing facts. Ordinary automation would retain the source enquiry, track ownership, and record whether the estimator accepted the handoff.
The coordinator would check the brief against the original message. Any uncertainty about what the customer requested would remain visible. The estimator would use professional judgment to decide whether the information is sufficient to begin the estimate.
The first version would support those two roles directly. It would not need a broad transformation program or a new performance score for every employee. The useful design question is whether one real enquiry can move between the roles with less reconstruction, less duplicate entry, and a clear record of what still needs attention.
The First Monday Enquiry
Give Staff A Way To Improve The Process
A coordinator who repeatedly corrects the same missing field has useful design information. The pilot should make it easy to identify the pattern and show an example. The team can then decide whether to change the intake question, the brief format, or the review instruction.
The feedback should address the workflow, not label a person as resistant. Someone may avoid the new process because a required fact has no place to go or because the estimator still asks for an old attachment. Those issues need a decision from the process owner.
Use short reviews tied to actual enquiries. Ask what the assistant prepared correctly, what required checking, and what happened at the handoff. Preserve successful habits from the old process when they serve a real purpose. Retire duplication when the replacement works, rather than keeping both paths indefinitely out of uncertainty.
| Current Illustrative Pattern | Proposed Pattern |
|---|---|
| Copy the enquiry into two places | Capture once in the agreed intake record |
| Email an attachment and hope | Require the estimator to accept the handoff |
| Measure logins and prompts | Measure accepted briefs and total effort |
Exceptions Need A Person And A Return Path
If a brief is incomplete, it remains with the coordinator. If the estimator is unavailable, a named backup accepts the handoff or the record shows that it is waiting. The assistant can prepare information while the team resolves availability, but it cannot treat an unattended notification as acceptance.
If the receiving system fails, the team uses the agreed fallback and records where the enquiry went. Once service is restored, the owner reconciles that request so the same enquiry is not processed twice. The fallback should preserve responsibility rather than create a second invisible queue.
The diagram shows the role changes explicitly. Its completion check asks whether the intake handoff was accepted, not whether the AI generated text. That is the event the people downstream depend on, and it is the event management should use when evaluating this particular pilot.
Use A Scorecard That Staff Recognize
Track the share of intake briefs accepted without a return, total handling minutes, time waiting for missing information, and the age of unresolved handoffs. Record duplicate entry separately so the team can see whether the old work was actually removed.
Include training, review meetings, technical support, and correction time in the evaluation. Tool logins and prompt counts may help diagnose use, but they do not establish that estimating received better information. A pilot with fewer logins could still be more useful if the process becomes simpler.
Review comparable enquiry types and report changes in volume or complexity. Let staff explain unusually difficult cases instead of hiding them inside an average. The scorecard should help the manager decide what to change next, while making clear which benefits are observed and which are still only expected.
| Measure | Purpose |
|---|---|
| Accepted intake briefs | Shows whether preparation supports estimating |
| Duplicate entry minutes | Checks whether old work was actually removed |
| Waiting and return rates | Reveals friction between roles |
| Training and support time | Counts the effort needed for adoption |
Define The Retirement Decision In Advance
The first build needs a small set of real examples, the current brief format, the intake rules, system access, and participation from the coordinator and estimator. The manager should name the condition under which duplicate entry will end and the fallback if the replacement fails.
During the initial comparison, a limited period of parallel checking may be useful. Give that period an explicit review point. Without one, a temporary check can become permanent extra work and undermine the purpose of the pilot.
Expansion should depend on the accepted handoffs and the team's ability to resolve exceptions. Add another enquiry type only when its required information and owner are clear. A process that works for a simple installation request may need different questions for a complex site assessment, even if the assistant can draft both.
Make Adoption A Change People Can Describe
A useful implementation leaves people able to explain their next action. The coordinator knows what to check. The estimator knows what to accept. The manager knows which old requirement has ended and where to intervene when work stalls. That shared agreement makes the tool part of the working day.
At SynHy, we could help map one handoff and define the first practical change. Bring the current intake examples, the document the next person actually uses, and the duplicate step nobody wants but everyone still performs. Those details give the pilot a concrete purpose.
The question after the demonstration is simple: what changes on Monday? If the answer names a useful behavior, an accepted outcome, and an old task that can be retired, the team has something specific to build and evaluate.