# The Quote Funnel Architecture: An Agent-Built Pattern > Source: > Published: 2026-08-23 00:00:00+00:00 Quote funnel architecture is the part of a multi-step quote flow nobody writes about: not the form design, not the conversion rate, but the trust-boundary and state-machine skeleton that has to be true underneath before any of that matters. This is the pattern we arrived at building a production quote funnel for a service business with coding agents doing most of the implementation — laid out generically, so it transfers to any vertical. The stakes are concrete. A quote funnel takes untrusted strangers on the public internet, walks them through several steps of self-reported detail, produces a number with commercial consequences, and hands the result to a CRM where real staff act on it. Every one of those hops is a place where a tampered request, a double-clicked submit, a bot, or a silently regressed status can corrupt the pipeline — and most of the published advice on quote flows never mentions any of it. This guide covers the six load-bearing decisions: server-authoritative state, a row-by-row trust boundary map, forward-only status transitions, resumability with idempotent submissions, honeypot-first bot defense, and an event-driven CRM handoff with signature and payment left as extension points. It is deliberately silent on conversion design — form length, field order, and step psychology are covered in our companion piece on [the conversion-design side of a quote flow](/blog/multi-step-quote-flow-design-conversion-2026). That post covers what makes people finish the funnel; this one covers what has to be true underneath before conversion optimization even matters. - 01The server owns price, stage, and every status.The client is a rendering surface. Price, stage, and status transitions are recomputed and validated server-side against stored state — OWASP's checklist language is blunt: all inputs validated on server regardless of client-side checks. - 02Status moves forward only — or explains itself.Forward-only transitions with a mandatory recorded reason for any backward move are a code-level answer to OWASP's named Workflow Order Bypass vulnerability class (BLA2:2025), not a UX nicety. - 03Idempotency keys make retries safe.A client-generated key on every submission means a retried request replays the saved result instead of creating a second lead — the same mechanism Stripe layers onto POST, with keys up to 255 characters held for at least 24 hours. - 04Honeypots and timing checks come before CAPTCHA.An invisible field plus a too-fast-to-be-human check is commonly reported to stop most automated submissions at zero friction. CAPTCHA imposes real abandonment cost, so it sits last in the defense ladder, not first. - 05CRM, signature, and payment are extension points.The handoff is an at-least-once webhook problem: verify, enqueue, respond, and dedupe by event ID. Signature and payment bolt onto the same state-machine-plus-webhook shape later — no core redesign required. ## 01 — The PatternOne funnel, two jobs — the client *proposes*, the server decides. Strip any multi-step quote funnel to its skeleton and you find two components with radically different trust levels. The client — the React app, the form wizard, the optimistic UI — exists to collect input and render the current stage pleasantly. The server owns everything that matters: the draft record, the rate tables, the stage pointer, and the rules for what can happen next. The entire pattern falls out of refusing to blur that line. The “agent-built” part is not incidental. Most of this funnel’s implementation was written by coding agents working from an explicit specification, and that changed the architecture for the better: an agent, like a hostile client, will happily produce code that does whatever the loosest interface allows. Explicit states, guarded transitions, and server-side invariants are exactly the constraints that make agent-written contributions safe to accept — the same wall that stops a tampered request stops a plausible but wrong code path from shipping. Constraints written down for the machine turn out to be constraints the machine can verify. ##### The *client* Collects input, renders the stage the server says the visitor is on, and gives fast feedback. It proposes values — a volume estimate, a preferred date, a service tier. Nothing it asserts about price, stage, or status survives the trust boundary unexamined. ##### The *server* Owns the draft record, recomputes price from tables the client never sees, validates every transition against stored state, and treats each request as untrusted until proven otherwise. Every rule in this post is a server-side rule. Everything that follows is an elaboration of that split: where exactly the trust boundary sits (Section 03), how the server stops the workflow itself from being gamed (Section 04), how it survives retries and abandoned sessions (Section 05), how it filters non-humans cheaply (Section 06), and how it exports its state to the systems where the business actually works (Sections 07–08). ## 02 — Trust BoundariesServer-authoritative state is a *security control*, not a style choice. The security literature has been unambiguous about this for years. OWASP’s [Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) phrases it as a checklist requirement, not a suggestion — and the same checklist requires that all access controls are enforced server-side, because authorization can never rest on what the client claims about its own permission state. *trust boundary crossing*.” — OWASP Secure Code Review Cheat Sheet. In a quote funnel, the trust boundary crossings are every step submission, the final submit, and every inbound webhook. For a quote funnel, the three assets worth naming explicitly are **price**, **stage**, and **status**. Price is recomputed server-side from rate tables the client never receives — the client may display a running estimate, but the number that lands in the CRM comes from the server’s own arithmetic over the server’s own inputs. Stage — which step of the funnel this visitor is on — lives in the draft record, keyed to the session or captured identity, so a crafted request cannot jump to “review and submit” without the server having seen the steps in between. Status — where the resulting lead sits in the pipeline — is governed by the state machine in Section 04. Client-side validation stays, but its job is honest: fast feedback for humans. The server re-validates everything, because the client’s checks run in an environment the visitor fully controls. This is also the discipline we hold agent-written code to when we [build these funnels for clients](/services/web-development): any handler an agent writes gets reviewed against one question first — what happens if every field in this request is a lie? ## 03 — The MapThe trust boundary *map*, step by step. The table below walks the funnel end to end and asks the same three questions at every step: what does the client send, what must the server independently verify or recompute, and what actually goes wrong if the server trusts the client instead. It is a pattern artifact — generalized architecture reasoning grounded in OWASP’s server-side validation and business-logic guidance, not a measured result from any single deployment. | Funnel step | What the client sends | What the server verifies or recomputes | If the server trusts the client | |---|---|---|---| | Core funnel steps | ||| | Contact capture | Name, email, phone — plus hidden honeypot and timing signals | Server-side format validation, bot signals (honeypot, elapsed time), dedup against existing records | Scripted identities flood the CRM; sales time burns on fabricated leads | | Service details | Selected service type, options, add-ons | Every selection checked against the catalog the server owns — unknown options and invalid combinations rejected | Quotes get generated for configurations the business does not sell | | Volume / inventory estimate | Item counts and any client-displayed running totals | Volume and price recomputed from raw item counts against server-held rate tables; client totals discarded | A tampered request sets its own price, and downstream systems honor it | | Scheduling preference | Preferred dates and time windows | Date sanity (not past, not beyond horizon) and availability checked against server-side calendars | Operations inherits bookings it cannot serve | | Review & submit | Final confirmation plus a client-generated idempotency key | Submission-level validation of the whole record; stored stage confirms every prior step was actually completed; key dedupes retries | Workflow order bypass — the final step fires without its prerequisites, or double-submits create duplicate leads | | Downstream & extension points | ||| | CRM handoff | (Server → CRM) webhook events, delivered at-least-once | Receiver verifies signatures and stores each event ID under a unique constraint — duplicates skipped, never reprocessed | Retried deliveries become duplicate CRM records and duplicate follow-ups | | E-signature (extension) | Provider webhook reporting envelope status changes | Webhook signature verified; named provider events mapped onto the funnel’s own state machine before any transition fires | Anyone who can POST to the endpoint can mark a quote “signed” | | Payment (extension) | A tokenized payment reference and provider status events | Provider-signed events verified; only the token stored — the raw card number never enters the funnel’s environment | Unpaid orders read as paid, and PCI compliance scope silently expands | Read the fourth column top to bottom and a theme emerges: none of these failures look like crashes. They look like plausible data quietly doing damage — a fake lead, a wrong price, an unserviceable booking, a premature “signed.” That is what makes trust-boundary failures expensive: they surface weeks later, in the CRM and in operations, long after the request that caused them is gone. ## 04 — Status IntegrityStatus moves *forward* — or it explains itself. Once a quote exists, its status becomes the most fought-over field in the system. Sales tools, automations, and humans all want to move it. The pattern’s rule is simple: transitions are **forward-only by default**, and any backward move requires an explicit, recorded reason — who moved it, from what, to what, and why. A regression without a reason is not a state change; it is a rejected request. Most workflow content treats step order as a UX nicety. Security guidance treats it as an attack surface with a name. OWASP’s Web Security Testing Guide carries a dedicated test, [Testing for the Circumvention of Work Flows](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/06-Testing_for_the_Circumvention_of_Work_Flows), aimed precisely at multi-step processes where the UI, not the server, enforces step order. Its architectural conclusion matches this pattern exactly: every multi-step workflow needs an explicit state representation stored server-side, keyed to the user or session, with each transition validated against the current stored state. [Concurrent Workflow Order Bypass (BLA2:2025)](https://owasp.org/www-project-top-10-for-business-logic-abuse/docs/the-top-10/workflow-order-bypass)as a distinct class: an attacker races a final workflow step through before required prior steps have fully applied. Forward-only, server-validated transitions are not process hygiene — they are the *direct countermeasure*to a documented vulnerability with a number. In code, the clean mechanism is a finite state machine with guarded transitions. Tooling like [XState](https://stately.ai/docs/machines) models the workflow as a fixed set of states plus explicit transitions, with guards — boolean conditions that must evaluate true before a transition may fire. “Backward moves require a recorded reason” stops being a convention in a wiki and becomes a guard the runtime enforces. Third-party engineering write-ups often credit this style with eliminating impossible states — combinations the database could physically store but that correspond to no valid real-world condition, like “signed” before “quote accepted.” That is their characterization rather than the library’s own claim. One buy-side note: this is the layer CPQ platforms sell you, packaged with their own pricing and workflow opinions. If the build-vs-buy question is live for your team, our [CPQ buyer’s guide](/blog/cpq-configure-price-quote-2026-buyers-guide) covers how the platforms package this same machinery. ## 05 — ResumabilityResumable by design, *idempotent* on submit. Real visitors abandon funnels mid-step, switch from phone to laptop, and lose connections on submit. The architecture answers with two mechanisms — a persistent draft, and idempotent submission. The draft side follows standard save-and-resume guidance for multi-step wizards: create a persistent draft record as soon as any stable identity exists (a session, an account, or just a captured email address) and save on **every step transition**, not only at final submission. Validation splits accordingly: step-level checks keep a step internally consistent so the visitor can keep moving, while strict submission-level validation of the complete record runs only at the final gate. A resumable funnel that hard-blocks on incomplete data mid-flow has defeated its own purpose. The submit side leans on a definition from the HTTP spec itself. RFC 7231 classes PUT, DELETE, and the safe methods as idempotent — POST, the method every form submission uses, is explicitly not. The spec also explains why the property matters: a client can safely retry an idempotent request after a communication failure without risking a duplicate effect, even if the original request actually succeeded server-side. "The intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request."— RFC 7231 §4.2.2, Idempotent Methods (IETF) Since POST is not idempotent by spec, the funnel makes it so — the same way [Stripe’s API](https://docs.stripe.com/api/idempotent_requests) does. The client generates a high-entropy key (Stripe recommends a V4 UUID and warns against building keys from sensitive data like email addresses) and sends it with the submission. The server stores the first result under that key and replays it to any retry. A double-clicked submit button, an impatient refresh, or a network timeout followed by a retry all produce exactly one lead. ##### Stripe idempotency key Client-supplied via the Idempotency-Key header, up to 255 characters. Stripe recommends V4 UUIDs or another random string with enough entropy to avoid collisions — and explicitly warns against sensitive data such as email addresses as keys. ##### Minimum key lifetime Stripe expires idempotency keys after a minimum of 24 hours. A key reused after expiry starts a fresh request rather than replaying the old result — so the retry-safety window is generous but not eternal. ##### Response replayed per key Stripe saves the status code and body of the first request under a key — including 500 errors — and returns that saved result to every reuse. Reusing a key with different parameters errors instead, catching accidental key reuse across two different operations. The parameter-comparison detail is the underrated part of the design. Deduplication alone would silently swallow a genuinely different second submission that accidentally reused a key; erroring on mismatched parameters converts a subtle data bug into a loud, debuggable failure. And per the spec’s own logic, idempotency keys belong only on the non-idempotent operations — Stripe declines them on GET and DELETE requests outright, “because it has no effect” there. ## 06 — Bot DefenseHoneypot first, CAPTCHA *last*. A public quote funnel is a lead form with commercial gravity, which makes it a bot magnet. The architectural question is not which single defense to pick but where each layer sits in the flow. The ordering principle: spend the visitor’s patience last. Invisible, zero-friction checks run first; anything that challenges a human runs only after the cheap layers have flagged a submission. The first layer is a honeypot — an input hidden from human view via CSS but present in the DOM. As one honeypot explainer from [OpenReplay](https://blog.openreplay.com/honeypot-fields-stop-bots/) puts it: “Since bots typically fill out every field they encounter, while humans only interact with visible elements, these invisible fields act as a silent alarm system for bot detection.” Industry write-ups commonly report that a honeypot alone cuts out most unsophisticated automated submissions, and that pairing it with a timing check — rejecting submissions completed faster than a human plausibly could — blocks the overwhelming majority of automated traffic. Treat those as directional pattern support, not measured guarantees: the commonly cited figures are blog-repeated aggregates with no controlled study behind them. CAPTCHA sits at the bottom of the ladder for the same directional reason: a meaningful share of legitimate users are commonly reported to abandon a form rather than complete a challenge. On a funnel whose entire purpose is capturing qualified strangers, an always-on CAPTCHA taxes every real visitor to catch bots the free layers would have caught anyway. ##### Honeypot field CSS-hidden input, present in the DOM. A filled honeypot marks the submission as automated. Return a silent success so the bot learns nothing. Zero friction for humans; catches indiscriminate form-fillers. ##### Timing *check* Record when the step rendered; reject completions faster than a human plausibly types. Catches scripted submitters that beat the honeypot. Still invisible to every legitimate visitor. ##### Rate limits + dedup Per-IP and per-identity rate limiting at the server, plus dedup against existing records before anything reaches the CRM. Catches volume abuse that per-request checks miss. ##### CAPTCHA Human challenge, reserved for submissions the earlier layers have already flagged as suspicious — never a blanket gate on every visitor. The one layer with a real abandonment cost attached. Honesty about the limitation is part of the pattern: honeypots only catch bots that indiscriminately fill every DOM field. Modern headless-browser bots render the page visually and skip CSS-hidden inputs, which is exactly why the ladder is layered — timing, rate limiting, and CRM-side dedup exist for the traffic a honeypot alone will not catch. Architecturally, the checks run server-side at the trust boundary, and a flagged submission gets a silent success response while never reaching the CRM. For the full implementation detail — field naming, accessibility, silent-200 mechanics — see [the honeypot-first bot-defense playbook](/blog/form-bot-defense-honeypot-first-playbook); this post only fixes where the layers sit in the architecture. ## 07 — CRM HandoffThe handoff is a *webhook* problem. A completed quote is worthless until it lands where sales works — the CRM. The naive implementation calls the CRM API inline during submit and hopes. The pattern treats the handoff as what it actually is: an event delivery problem with well-understood failure modes and a standard shape. Webhook providers universally choose [at-least-once delivery](https://hookdeck.com/webhooks/guides/webhook-delivery-guarantees) over at-most-once — silently dropping a real event is judged worse than occasionally double-sending one. Accepting that trade means accepting its consequence: the receiving side must expect and tolerate duplicates. ##### At-least-*once* Failed deliveries are retried on a backing-off schedule that can span days before a persistently failing endpoint is disabled — behavior documented across providers and summarized by independent implementation guides. Every retry is a potential duplicate at the receiver. ##### Idempotent *processing* Store each event's unique ID in a table with a unique constraint; skip any ID already seen. Verify the signature, enqueue the payload, return 200 immediately — the actual CRM write happens in a background worker, so a slow CRM API never causes upstream retry storms. The verify–enqueue–respond shape earns its keep twice. It decouples “we accepted the event” from “we finished processing it,” which keeps the funnel responsive regardless of CRM latency; and it gives retries a safe surface, because the dedup table makes reprocessing a no-op. This is the same idempotency idea from Section 05 applied one hop downstream — the funnel is idempotent toward its visitors, and the CRM receiver is idempotent toward the funnel. We keep the deeper mechanics in [a full reference on webhook idempotency and retries](/blog/webhook-reliability-idempotency-retries-engineering-reference-2026); the architectural point here is only where the extension point sits. What happens after the record lands — routing, assignment, response-time SLAs — is its own discipline with its own failure modes, covered in [our lead-routing and SLA framework](/blog/lead-routing-assignment-2026-crm-sla-framework). And if the CRM side of the pipeline is where your bottleneck actually lives, that is the territory of our [CRM automation engagements](/services/crm-automation) rather than this post. ## 08 — Extension PointsSignature and payment as *extension points*, not features. The most consequential thing the pattern says about e-signature and payment is when to build them: later, and against the seams the architecture already has. Both bolt onto the same state-machine-plus-webhook shape that already governs the CRM handoff — which is precisely why they can wait without accruing redesign debt. ### The signature extension An e-signature provider is, from the funnel’s point of view, a state machine of its own that reports transitions by webhook. [DocuSign’s Connect system](https://developers.docusign.com/platform/webhooks/connect/event-triggers/), for instance, fires distinct named envelope-status events — envelope-sent, envelope-delivered, envelope-declined, envelope-voided — and [DocuSign’s own developer guidance](https://developers.docusign.com/platform/webhooks/) recommends webhook push over polling for status, citing system-resource savings. The integration is therefore a mapping exercise: each named provider event becomes a guarded transition in the funnel’s state machine, arriving through the same verify–enqueue–respond receiver the CRM handoff already uses. ### The payment extension Payment attaches through tokenization. The core PCI DSS principle, per [PCI compliance guidance](https://www.securitymetrics.com/blog/what-tokenization-and-how-can-i-use-it-pci-dss-compliance): capture the card number once, replace it with a token, and never store the raw primary account number in your own environment again. Tokenization does not eliminate PCI DSS obligations, but it narrows their scope — fewer systems handle raw cardholder data, which [payment-orchestration guidance](https://www.ixopay.com/blog/the-benefits-of-tokenization-for-reducing-pci-scope) says can lower the required Self-Assessment Questionnaire level. The funnel stores the token and listens for provider-signed status events; the card number never crosses its trust boundary at all. *a guarded state transition plus an idempotent webhook receiver*— without touching the trust boundary map. Signature and payment both pass. Anything that fails the test is not an extension; it is a redesign wearing a plugin costume. ## 09 — ConclusionA pattern that outlives its *first build*. ### The client proposes. The server decides. Everything else is an extension point. Six decisions carry the whole pattern: the server owns price, stage, and status; every trust boundary crossing gets verified; transitions move forward or explain themselves; submissions are idempotent and drafts survive abandonment; bots meet invisible defenses before any human meets a challenge; and the CRM, signature, and payment integrations all speak the same event-driven dialect. None of it is exotic — *every mechanism here is documented* in a public spec, an OWASP checklist, or a provider’s developer docs. The pattern is the assembly, not the parts. The forward-looking claim is about agents. As more production code gets written by coding agents, architectures that encode their invariants as machine-checkable constraints — explicit states, guards, unique keys, signed events — will compound in value, because they are precisely the architectures an agent can extend without silently breaking. The funnel this pattern comes from was largely agent-written, and the constraints are why that worked. We expect the pattern to matter more, not less, as the share of agent-written code grows. If you take one thing: draw your own trust boundary map before optimizing anything. Conversion work tunes how many people finish the funnel; this architecture decides whether what comes out the other end can be trusted. Get the second one right first.