Construction
The form decides who gets the owner's diary, and the handover writes itself
One qualification question routes the enquiry before anyone reads it, every meeting and call is attributed to the stage it belongs to, and the whole deal history assembles into a handover package when the bid closes.
Client: A contractor bidding on hotel renovation projects
System flow and narrative
Hotels operated: 8 or more. Meeting evidence: Type recognised. Path: Enquiry form, then Contact upsert, then Hotel count gate, then Owner booking page, then Kickoff booked, then Meeting recording, then Call transcript, then Meeting type match, then Meeting type tag, then Pipeline stage move, then Bid won, then Bid lost, then Handover assembly, then Handover workbook, then Evidence document.
The form decides who gets the owner's diary, and the handover writes itself: system flow
Edges: live is a thicker, full-opacity, travelling dashed line; not taken is a thinner, dimmed, solid line. Nodes: live is a thicker, full-opacity outline; not taken is a thinner, dimmed outline. Color is never the only signal.
01
One field decides where the enquiry goes
The enquiry form asks how many hotels the company operates, and that single answer chooses one of three destinations before a person has read anything: eight or more goes to the owner's booking page, three to seven goes to business development, and two or fewer goes to a thank you page and a call made by hand. The bands are continuous and mutually exclusive, so every answer falls in exactly one. The interesting case is the answer the system cannot read. An unreadable or missing count resolves to the lowest band rather than to an error, which sends it to a person instead of into the owner's calendar. A gate that fails towards a human is the only kind worth putting at the front door.
02
The record is written on every submission, not just the first
The form posts to the orchestration layer while the visitor's browser is being redirected, so the routing and the record happen together rather than one after the other. The board shows them in sequence because everything downstream attaches to a record that has to exist first. The write is an upsert rather than a create, which is what lets a prospect correct a typo in their own email without producing a second contact. The note attached alongside it is guarded differently, by reading back what the record already holds before writing, because a note append is not idempotent and a double submit would otherwise leave two identical copies. Those are not the same problem and they do not have the same fix.
03
Every conversation lands on the deal as evidence
Once a kickoff is booked, two channels feed the deal continuously. Meeting recordings arrive from the meeting workspace when a recording is ready, and phone calls are transcribed and stored as notes on the same opportunity. Both are checked against what the record already carries before anything is written, so a redelivery does not duplicate a transcript. Neither channel asks anyone to file anything, which is the point: the material that a handover eventually needs is captured while the deal is live rather than reconstructed at the end of it.
04
What happens when it cannot tell which meeting that was
A transcript is only useful if the system knows which meeting it came from, because the meeting type is what drives the stage move. The system matches the recording against the contact's appointments and reads the type from the one it finds. When it matches, the transcript is tagged and the tag moves the deal. When nothing matches with enough confidence, it does not guess: it raises a review prompt, assigns it to the CRM manager, and sends an email carrying four links, one per meeting type. Clicking one sets the type and releases the same stage move. Each of those four links drives its own single purpose workflow rather than one workflow branching four ways, because the branching construct is what had failed before.
05
The stages move themselves where the platform allows it
Stage moves are driven by events rather than by anyone remembering to drag a card. An inbound email carrying an attachment is what marks the improvement plan as received. The proposal stage is detected by a scheduled scan of the sent mailbox, so the deal moves when the proposal actually goes out rather than when someone gets back to the CRM. Every move is written to the deal's own history. Where the platform genuinely cannot see something, the system prompts a person instead of inventing a state, and the known limits of that arrangement were documented rather than papered over.
06
The package the delivery team actually inherits
Both terminal outcomes trigger the assembly, not just the winning one, because a lost bid is worth the same record. The job reads the full deal history, chunks long content to fit the cell limits of the destination, and produces an evidence document and a workbook that opens with a written synthesis of the deal. Both are filed into that deal's own folder, and the links are written back before either is moved, so a file that cannot be moved costs nothing. The notification is held until the assembly reports completion rather than released on a timer, which means it carries real links or it sends nothing at all. An assembly that finds a package already there reuses it instead of building a second.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| Hotels operated is 8 or more | Owner booking page | the largest operators are worth the owner's time |
| Hotels operated is 3 to 7 | Sales booking page | mid sized operators go to business development |
| Hotels operated is 0 to 2 | Qualifying call | an unreadable or missing count lands here too |
| the caller confirms a live renovation project | Kickoff booked | |
| no renovation project is in prospect | Not viable | |
| a recording is published for the appointment | Meeting recording | |
| a call on the deal ends and is worth transcribing | Call transcript | |
| Meeting evidence is Type recognised | Meeting type tag | the recording matches an appointment whose meeting type is known |
| Meeting evidence is Needs review | Needs review prompt | nothing matches it with enough confidence to act on |
| the meeting type tag lands on the contact | Pipeline stage move | |
| a reviewer clicks one of the four meeting type links | Pipeline stage move | |
| the deal reaches the won stage | Bid won | |
| the deal reaches the lost stage | Bid lost |
The stack.
| Layer | Tools |
|---|---|
| Enquiry capture | WordPress, Elementor Pro |
| CRM and pipeline | GoHighLevel |
| Orchestration | n8n |
| Meeting and call evidence | Fathom, GoHighLevel Voice Intelligence |
| Calendars | GoHighLevel, Microsoft 365 two way sync |
| Handover output | Google Docs, Google Sheets, Google Drive |
Safeguards.
- The contact write is an upsert on every submission, so a prospect correcting their own typo updates one record rather than creating a second.
- The note write is guarded by reading back what the record already holds, because a note append is not idempotent and a double submit would otherwise leave two identical notes.
- An unreadable or missing hotel count resolves to the lowest band, so a misread enquiry reaches a person instead of the owner's calendar.
- The count is read as the first run of digits rather than every digit joined, so a banded answer cannot be read as a number it does not contain.
- Every active workflow is registered with a shared failure alert, so a failed run raises an alert rather than sitting in a log.
- The handover notification waits for the assembly to report completion rather than for a fixed delay, so it carries real links or it sends nothing.
- The assembly checks for an existing package before it builds, so a repeated trigger reuses the package rather than producing a second one.
Before and after.
- Who gets the owner's diary
- Before: Every enquiry was triaged by hand, and the owner's time went to whoever asked firstAfter: The form routes by the size of the operator before anyone has read it
- An enquiry the system cannot read
- Before: A misread answer could put a small prospect in the owner's calendarAfter: Anything unparseable falls to the band a person handles
- Meeting attribution
- Before: Someone had to remember which meeting a recording belonged toAfter: The recording is matched to its appointment and the meeting type drives the stage
- When attribution fails
- Before: An unattributed recording sat unfiled and the deal stopped movingAfter: A review prompt is raised and assigned, and one click sets the type
- Deal history at handover
- Before: The delivery team started from whatever the salesperson rememberedAfter: Transcripts, correspondence and notes assemble into one workbook
- The handover notification
- Before: A timed message could announce a package that did not exist yetAfter: The notification waits for the assembly to confirm the links
This is one delivered system, published in full. See how we build AI automation
Want this on your own stack? See our GoHighLevel development and n8n automation agency pages.
Start a conversation
Tell us what you’re building.
Share the essentials and we’ll reply within 4 hours with a real next step, not an auto-responder.
What happens next
- We reply within 4 hours, from a real person, not an auto-responder.
- A short scoping call to understand the goal, constraints, and timeline.
- A fixed-scope discovery sprint: a working prototype and a written estimate.
- info@irenictech.com
- Office
- Austin, TX, United States
- Hours
- Mon–Fri · Async + scheduled calls