INTERNAL TOOLS · AI WORKFLOW DESIGN
AI Proposal Assistant
Client
Xcalibre Protective Services
Role
Sole designer and builder
Timeline
2026
Platform
Internal AI Proposal Assistant
~10 min
Proposal preparation
Down from 2+ hours per proposal
11
Required fields enforced
No proposal generates until every one is filled
0
Missing info is asked for, never guessed
He tested it from the first prototype
My role
Designed and built it myself, embedded with operations. The field commander was my user and tester from first prototype to daily use.
Team
Owner · Field Commander · Operations
Scope
Workflow Analysis · Conversational UX · AI Interaction Design · Prompt Architecture · Prototyping · Apps Script Development · Testing · Implementation
Tools
Google Apps Script · Gemini API · Google Docs · HTML/CSS/JavaScript · Google Workspace · ChatGPT
01 Context
The obvious solution was a form. It was also the part he didn’t want to use.
The company needed a faster way to turn rough job details into client-ready security proposals. The existing process took more than two hours and involved pulling information together, filling gaps, rewriting it into proposal language, and formatting the final document.
The initial request was to build a form, and that made sense on paper. But the field commander who would actually use it hated forms. He already knew most of the job details before he started, and he was comfortable explaining them conversationally in Gemini.
So I started looking at the proposal process from his side: what he already knew, what the proposal still needed, and where the time was actually being lost.
Mapping the existing and proposed workflows showed where manual review, follow-up, re-entry, and formatting were adding time to proposal preparation.
Once the details are reviewed, the assistant generates the final proposal and gives the commander a direct link to open, edit, or share the Google Doc.
02 Discovery
The fastest part of the process was the part already in his head.
I looked at what every proposal needed, how the commander naturally described a job, and where the existing process was creating extra work. The proposal still needed a consistent structure, but the commander didn’t need to think in that structure from the beginning.
Discovery 01
The commander already knew the job.
He usually knew the staffing, schedule, responsibilities, client expectations, and operational details before he started. Most of the work came from translating what he already knew into the format the proposal required.
Discovery 02
A traditional form added another translation step.
A form would have broken every requirement into individual fields and produced very clean input. It also would have required the commander to stop, decide where each piece of information belonged, and work through the system in an order that did not match how he naturally described the opportunity.
Discovery 03
Conversation was already familiar.
He was comfortable typing into Gemini, explaining what he knew, answering questions, and correcting information conversationally. The commander could start with whatever information he already had. The system could extract the useful details, compare them against the proposal requirements, and ask for anything that was still missing.
The finished workflow was designed for real field use, giving staff a mobile way to turn incomplete job notes into a review-ready proposal.
The assistant identifies what is missing from the initial notes and asks only for the details needed to complete the proposal.
03 Decisions
Give the conversation flexibility and keep the business rules predictable.
The assistant needed to understand rough, incomplete input without becoming responsible for deciding what belonged in the proposal. I kept the conversational layer flexible while defining much tighter rules around required information, follow-up behavior, review, and document generation.
Decision 01
Start with what the user already knows.
The workflow opened with one simple prompt asking the commander to describe the opportunity in his own words. He could paste rough notes, type whatever he already knew, and keep moving. The system pulled out the details it could use and carried them forward, so he didn’t have to stop and re-enter the same information somewhere else.
Tradeoff 01
Open input is messier to parse than a form, so the system had to do the organizing work a form would have pushed onto the user.
Decision 02
Ask for missing information instead of filling in the blanks.
The assistant checked what the proposal still needed and asked for anything that was missing. That mattered because staffing, schedules, responsibilities, and client details could not be guessed safely. The model could help organize the information, but it was never allowed to invent operational details just because an answer sounded plausible.
Tradeoff 02
More follow-up questions, in exchange for a proposal that never contains invented details.
Decision 03
Use structured controls where precision mattered.
Not everything belonged in a conversation. Details that had to be exact used structured controls, and the commander reviewed everything before the proposal was generated.
Tradeoff 03
A review step before generation added one more screen to a workflow built for speed.
04 DELIVERY
I built the assistant around the parts AI could help with, and kept the risky parts tightly controlled.
I carried the project from the original request through workflow analysis, conversational design, prompt behavior, prototyping, development, testing, and implementation in Google Apps Script.
The application had to keep track of what information had already been provided, what the proposal still required, and what question should come next. I defined the proposal requirements and translated them into prompt logic and application behavior so the conversation could stay flexible without losing the structure the business needed.
Because I was also building the tool, design and implementation happened in the same loop. I tested the workflow with the field commander and adjusted it when questions became repetitive, unclear, or unnecessary. When the model behaved outside the intended process, I changed the prompt, workflow logic, or interface and tested it again.
Before generating the final Google Doc, the system showed the extracted information back to the commander for review. He could correct anything that was wrong and fill in anything still missing. The final workflow moved from rough opportunity details to a reviewed, structured proposal without making him manually organize the information first.
I also designed for when it would go wrong. His raw notes are saved to an intake log before the model ever sees them, so a failed call never loses what he typed, and every failure is logged with its error. The model only extracts. It can't make pricing, staffing, or legal decisions, service types have to match an approved list, and details like armed status or an end date only fill in when the notes say so outright. Anything the model can't confirm stays blank and comes back as a follow-up question. Calculations like daily guard hours run in code, not in the model. And the proposal can't be generated until every required field is filled, including conditional ones, like a vehicle rate whenever vehicles are included.
The Proposal Assistant starts with one open prompt so the commander can enter rough job details in his own words before the system organizes the information and asks for anything missing.
The completed workflow generated a structured, review-ready security proposal in Google Docs, carrying the information collected through the assistant into a usable client deliverable.
The conversational front end was backed by structured logic, validation, and business rules implemented in Google Apps Script.
05 IMPACT
Proposal preparation dropped from more than two hours to about ten minutes.
The finished tool condensed proposal preparation into one guided workflow. The commander could start with the information he already had, answer a small number of follow-up questions, review the structured details, and generate the proposal.
What used to take 2+ hours of gathering, rewriting, and formatting now takes about 10 minutes, from rough notes to a finished Google Doc.
The completed workflow moves from rough job notes through targeted follow-up questions, structured inputs, review, and final proposal generation.
06 REFLECTION
The best workflow is the one someone will actually use.
A form would have been easy to build, but it depended on the commander being willing to stop and work through a structured set of fields every time a proposal was needed. That was not how he preferred to work, and it made the process much more likely to be delayed or skipped. Starting with conversation let him begin with what he already knew while the application handled the structure behind it.
That ended up being the bigger lesson for me. A workflow can be perfectly organized and still fail if it asks too much of the person using it. The AI mattered here because it let the system absorb more of that structure instead of pushing it back onto the commander.
