Where this proof applies
- Founder-led service businesses with workflow bottlenecks and manual lead handoffs
- B2B SaaS teams that need qualification logic before calendar access
- Operators who need a lean RevOps baseline before outbound scale
Back to work
Internal system teardown (not a client case study)
Qualified intake routing and secure fit-call booking pass for Zynovex
This asset documents Zynovex's own commercial-funnel rebuild. It is published as internal implementation proof, not as client delivery proof.
Status
Public proof asset
Published
2026-04-02
Last validated
2026-04-02
Proof type
Internal system teardown (not a client case study)
Problem context
- Lead capture and qualification needed to shift from a generic contact path to a filter that protects founder time.
- Qualified leads needed a secure booking path with attribution continuity instead of open calendar links.
- The funnel needed operational diagnostics so configuration drift could be detected before losing demand.
What was implemented
- Built `/start` as a qualification-first intake path with explicit fit and no-fit framing.
- Implemented `/api/qualification` scoring and route decisions: `qualified`, `manual_review`, `disqualified`.
- Added signed booking-pass routing via `/api/revops/booking-pass` with controlled fallback behavior.
- Added critical RevOps event relay endpoint and allowlist in `/api/revops/event`.
- Added protected readiness diagnostics endpoint `/api/revops/readiness` plus acceptance scripts for repeatable checks.
Architecture summary
- Next.js App Router with server routes for qualification, booking-pass redirect, event relay, and readiness reporting.
- Lead routing logic is encapsulated in `src/lib/revops/lead-routing.ts` with explicit score thresholds and disqualification reasons.
- Lead delivery guardrails enforce at least one successful sink for non-disqualified submissions before returning success.
- HubSpot and Plausible integrations are environment-driven so production wiring can be tightened without code changes.
Defensible evidence available now
Code-level evidence
Qualification, booking-pass, event relay, readiness diagnostics, and lead-delivery guardrails are implemented in the repository.
Automated coverage evidence
Tests exist for lead routing, booking-pass integrity, lead-delivery enforcement, qualification API behavior, and critical event relay.
Production acceptance evidence (documented 2026-04-02)
Progress tracker records `overallStatus=ready` and both acceptance suites passing 5/5 checks for production.
Tradeoffs and constraints
- No client-identifying data is exposed because this is internal proof, not a customer case.
- Current proof is strongest on system design and operational discipline; external business outcomes require founder-approved client releases.
- Routing rigor intentionally increases friction for low-fit inbound to protect calendar quality.
Founder input still required
- First founder-approved external case package with client context, baseline bottleneck, implementation scope, and measurable outcome language.
- Approval policy for anonymized result statements and what can be published publicly versus only shared in private sales conversations.
- Optional screenshot or architecture artifact approvals that can be shown on public proof pages.
Need this level of funnel control for your team?
Route your use case through the qualification path and we can determine fit for a scoped paid discovery sprint.