One POST fires the entire funnel.

The 60-second version

A visitor answers three questions. A scoring engine ranks their intent and picks the right next step. On submit, one request stores the lead, sends it to the CRM, emails the team and the prospect, and records a conversion in GA4 — with a browser event trail the whole way.

The problem it solves

Braven's institutional buyers — a city economic-development office, a county, a chamber, a foundation — are not the same buyer. They have different money, different timelines, and different definitions of success. A single generic “Contact Us” form treats them identically and leaks the ones who were ready to move.

So the tool does three things a form can't: it self-segments the visitor, scores their intent transparently, and routes each one to the next step that actually fits — while capturing everything downstream systems need.

Big-picture architecture

One design decision shapes everything: the routing brain has no WordPress dependency. It's plain PHP that takes a selection and returns a decision. WordPress is a thin adapter layer wrapped around it. That's why the logic is trivial to test and reason about, and why the tool is honest to document.

The request lifecycle

Two REST calls, deliberately split. The first computes a routed view with no personal data. The second — only after the visitor commits — captures and fans out. Here's the full sequence.

The routing engine, in full

This is the part the “Routing Test” asks about. It's deliberately transparent: every answer carries points, the sum picks a tier, and a short ordered rule list turns (buyer type, tier, funding posture) into an outcome. All of it is config in data/routes.php — the engine just reads it.

Step 1 — Score the answers

Step 2 — Map the score to a tier

Step 3 — Resolve the outcome (first match wins)

Worked examples

The code

// class-blr-routing-engine.php — the whole decision, no side effects
public function decide( array $selection ) {
  $score    = $this->score( $answers, $buyer_type );   // sum of points + segment weight
  $tier_key = $this->tier( $score );                  // A / B / C by threshold
  $outcome  = $this->resolve_outcome( $buyer_type, $track, $tier_key, $answers ); // first match
  return [
    'tier' => $tier_key, 'outcome' => $outcome_key,
    'headline' => $outcome['headline'], 'form_fields' => $outcome['form_fields'],
    'value_prop' => $bt['value_prop'], 'track_label' => $tk['label'], /* … tailored copy … */
  ];
}

The data model

Right tool per job. Leads and videos are Custom Post Types (they want an admin UI, search, REST, and ACF). The webhook delivery log is high-volume append-only audit data, so it's a real custom table. Videos get two taxonomies so terms stay indexed and filterable.

Why a CPT for leads but a table for deliveries?

A CPT gives leads the entire WordPress ecosystem for free — the admin list, search, capabilities, export, and (critically for Braven's stack) ACF Pro field groups mapping straight onto the same _blr_* meta keys. Delivery attempts are different: many rows per lead, write-heavy, never edited. That's a table with indexes on lead_id and idem_key, created via dbDelta() on activation.

// class-blr-cpt.php
register_post_type( 'blr_lead', [ 'public'=>false, 'show_ui'=>true, 'show_in_rest'=>false ] ); // private: no public URL, no public REST
register_taxonomy( 'blr_track', 'blr_video', [ 'hierarchical'=>true, 'show_admin_column'=>true ] );

The capture pipeline

One POST to /braven/v1/lead runs four stages in order. Each degrades safely — a failed email never fails capture, an unconfigured CRM is recorded rather than thrown. The lead is captured no matter what downstream does.

// class-blr-rest.php — the orchestration, trimmed
public static function post_lead( $req ) {
  if ( ! self::verify_nonce( $req ) ) return 403;          // CSRF
  $decision = ( new BLR_Routing_Engine )->decide( $selection ); // recompute — never trust client
  $result   = ( new BLR_Lead_Validator )->validate( $params, $decision['form_fields'] );
  if ( $result['errors']['_spam'] ) return 200;             // silent to bots
  if ( ! $result['ok'] ) return 422;                       // field errors

  $lead_id = ( new BLR_Lead_Repository )->save( $lead, $decision );          // 1. persist
  $crm     = ( new BLR_Webhook_Dispatcher )->dispatch( $lead, $decision, $lead_id ); // 2. CRM
  ( new BLR_Email_Workflow )->run( $lead, $decision, $lead_id );               // 3. email
  ( new BLR_GA4 )->generate_lead( $decision, $ga_client_id );                  // 4. GA4
  return [ 'ok'=>true, 'lead_id'=>$lead_id, 'crm'=>$crm, 'destination'=>$dest ];
}

The CRM handoff

The lead POSTs to a configurable webhook — Braven's Smrts CRM inbound hook, or a Zapier/Make catch-hook. The payload is CRM-neutral and signed; delivery is idempotent and retried; every attempt is logged and shown in the admin Routing Console.

The payload

{
  "idempotency_key": "a1b2…",               // dedupe/upsert key (also an X-Braven-Idempotency header)
  "lead_id": 30,
  "contact": { "name":"…", "title":"…", "email":"…", "phone":"…", "organization":"…" },
  "segmentation": {
    "buyer_type":"city", "track":"ai",
    "intent_tier":"A", "intent_score":120,
    "outcome":"book_call", "priority":"hot"
  },
  "notes": "…goals…", "consent": true,
  "attribution": { "utm_source":"…", "gclid":"…" },
  "source": "braven-lead-router", "page_url":"…", "submitted_at":"2026-…Z"
}

Mapping to Smrts (or any CRM)

Reliability

Tracking & GA4

Two layers. The browser pushes a clean event to dataLayer at every step for GTM. The server independently fires the conversion (generate_lead) via the GA4 Measurement Protocol — so a lead is recorded even when an ad-blocker or a bounce kills the client beacon. That redundancy is the “server-side tagging a plus.”

Wiring it in GTM

For each blr_* event: a GA4 Event tag on a matching Custom Event trigger; map buyer_type, track, intent_tier, outcome to registered GA4 custom dimensions. The GTM container prints into wp_head only when a container ID is set — nothing loads otherwise.

The wizard front-end

Progressive enhancement over server-rendered markup: the questions exist in the DOM before JavaScript runs. router.js is a tiny (~7KB, no jQuery) state machine that handles transitions, focus, REST calls, and the dataLayer.

• Auto-advance on the single-choice steps (buyer type, track) keeps it snappy; qualifiers wait for an explicit “See my path”.
• Focus moves to each new step and errors are announced via an aria-live region.
• The routed form is built from the decision — the server tells the client which fields to collect, so the form matches the outcome (a booking confirm asks for less than a proposal intake).
• GA client id + UTMs are read client-side and sent with the capture so server-side GA4 stitches to the same session and the CRM gets attribution.

How it lives inside WordPress

Everything is stock WordPress — no core hacks, no exotic dependencies. One plugin folder in wp-content/plugins/ plus a hello-elementor child theme. Drop it into any WordPress 6.4+ site and activate.

ACF Pro — a first-class citizen, never a hard dependency

Without ACF, meta is registered/typed and the admin shows a native panel. With ACF Pro (Braven's stack), the shipped field groups in acf-json/ take over the UI, bound to the same _blr_* keys — zero migration. ACF simply upgrades the interface.

Shortcode and Elementor — one renderer

Deep logic in PHP; Elementor stays clean. The “Braven Lead Router” widget carries no logic — it calls the shortcode renderer, so there's exactly one implementation. (Load-order note: the widget subclasses extend \Elementor\Widget_Base, which isn't available at plugins_loaded, so they're declared lazily inside the elementor/widgets/register callback.)

REST API reference

# Try the routing brain live — no auth, no PII:
curl -s -X POST https://braven-demo.levelbrook.com/wp-json/braven/v1/route \
  -H 'Content-Type: application/json' \
  -d '{"buyer_type":"foundation","track":"ai","answers":{"funding":"seeking","timeline":"year","role":"recommend","scale":"m"}}'
# → outcome: funding_partnership  (the foundation rule beats the tier)

Performance — how PageSpeed stays > 90

By removing weight, never by adding plugins. The whole thing is built to load almost nothing.

Accessibility (WCAG 2.1 AA)

Braven's audiences are government and institutional, so accessible builds are non-negotiable. Built in from the start, not bolted on.

• Each question is a <fieldset> with a <legend>; options are real <input type="radio"> inside a role="radiogroup" — keyboard operable, screen-reader correct.
• Visible focus states on every control (never outline:none without a replacement).
• Step changes move focus to the new step and are announced via aria-live; errors are announced too.
• Colour contrast meets AA; state is never colour-only.
• Server-rendered questions work without JavaScript; a <noscript> fallback offers a phone number.
• prefers-reduced-motion disables the shake/entrance animations.

Security

The deploy stack

The live demo is a single self-contained container: FrankenPHP (PHP 8.4) serving a real WordPress + Elementor install on SQLite — no MySQL — behind an auto-TLS reverse proxy.

• First boot self-provisions headlessly via WP-CLI: installs core, the SQLite integration, Elementor, the plugin, and the child theme, then seeds pages, the menu, the video library, and settings.
• The SQLite database lives on a mounted volume, so it survives image rebuilds.
• Assets aside, the whole demo is reproducible from the repo: docker build → docker run → register the proxy route.

Testing

The routing brain has no WordPress dependency, so the entire contract is unit-tested with plain php tests/test-routing.php — 26 assertions, no database, no HTTP server.

Extending it — the Phase 2 AI seam

Braven's spec: their AI team owns the generative logic; the engineer architects the hooks so it plugs in without a rebuild. The seams are already here.

Glossary