← all hypotheses

Resolution Promise Gate for SaaS Support Teams

ranked [TRIANGULATED] filter 6.5/15 spread ±2.0 signals: 2 independent
What is this?
A pre-send checkpoint that grades customer-facing resolution-time commitments before they leave the support agent — human or AI — to the customer. Built for support ops leads at 50-300 person B2B SaaS running mixed human + AI L1/L2 functions on Zendesk, Intercom, or Freshdesk. The product ingests ticket categories, historical close times, and current backlog metadata via webhook. Each outbound ETA is scored against patterns of similar past commitments and current backlog. The 6-pattern autopsy taxonomy detects Cosmetic Confidence (round-number Friday ETAs unjustified by complexity) and Temporal Blindness (commitments that ignore queue depth). Adversarial multi-model debate stress-tests the proposed ETA against historical breach patterns; the structured constraint language layer adapts per category weekly using Zendesk close times as ground truth — no manual rule maintenance. Why AE specifically: support over-promising follows the same epistemic failure patterns AE's autopsy taxonomy was built to detect; the sub-24h grading loop matches ticket resolution windows; category-level metadata avoids any extraction from ticket content.
Why did we consider it?
Every 2026 support vendor competes on resolution rate but nobody grades the ETA promise itself — AE's autopsy taxonomy + sub-24h reality-graded loop fits that gap precisely, with a webhook-only data model that solo-sells to UK support ops leads.
What breaks?
  • Architectural impossibility: A webhook-only model is asynchronous and cannot act as a pre-send UI checkpoint without introducing severe latency or requiring complex Zendesk/Intercom app integrations.
  • Behavioral mismatch: L1/L2 support agents actively avoid giving hard ETAs, meaning the system will either starve for actionable data or generate workflow-breaking false positives on soft deflections.
  • Commander constraint violation: Deploying, updating, and maintaining synchronous, low-latency UI blockers across multiple helpdesk platforms is unfeasible for a part-time solo developer.
Fatal objection: Pre-send gating requires write-path helpdesk integrations across three platforms that a solo builder cannot sustain and incumbents owning the compose surface will trivially replicate.
What did we learn?
Still in evaluation (phase: ranked). No verdict yet.

Filter scores

Five axes, each scored 0-3. Three independent runs by different model perspectives. Median shown.

AxisWhat it measures
data moatDoes this product accumulate proprietary data that compounds?
10x model testDoes a better model make this more valuable, or redundant?
fast feedback loopsCan outputs be graded against reality in <30 days?
solo founder feasibleCan a solo operator build and run this without a team?
AI providers cant eat itDo hyperscalers have structural reasons NOT to build this?
Composite median: 6.5 / 15. Graduation threshold: 9.0. IQR across runs: 2.0.

Evidence

Signal B — Competitor with documented gap

Gleap and similar autonomous AI support agents (also Fini at usefini.com) focus on resolving tickets end-to-end — 'resolve up to 80% of tickets' — but none describe a pre-send checkpoint that grades outbound resolution-time commitments against historical patterns and current backlog before they reach the customer. The entire category optimizes for ticket deflection and resolution, not for validating the realism of ETA promises.

Signal D — Demand proxy

{"found":true,"summary":"Active discussion across Reddit, Hacker News, and LinkedIn about AI support quality gaps, over-promising, and the disconnect between AI support tool marketing claims and real-world reliability — directly adjacent to the 'resolution promise' problem space.","sources":["https://www.reddit.com/r/SaaS/comments/1ngndvg/the_truth_about_ai_agents/","https://news.ycombinator.com/item?id=43683012","https://www.linkedin.com/posts/david-heinemeier-hansson-374b18221_maybe-one-day-ai-will-answer-every-customer-activity-7302238045657841664-XBzH","https://www.linkedin.com/posts/sajit…

Evaluation history

WhenStagePhase
2026-05-14 08:43evidence_searchranked
2026-05-14 08:18evidence_searchranked
2026-05-14 07:48evidence_searchranked
2026-05-14 07:18evidence_searchranked
2026-05-14 05:42evidence_searchranked
2026-05-14 05:13evidence_searchranked
2026-05-14 02:12evidence_searchranked
2026-05-14 01:49evidence_searchranked
2026-05-14 01:25evidence_searchranked
2026-05-14 01:00evidence_searchranked
2026-05-13 21:48evidence_searchranked
2026-05-13 16:30evidence_searchranked
2026-05-10 15:48evidence_searchranked
2026-05-10 15:06evidence_searchranked
2026-05-10 14:24evidence_searchranked
2026-05-10 08:42fatal_objectionranked
2026-05-10 08:36fatal_objectionranked
2026-05-10 08:30filter_scorescored
2026-05-10 08:24filter_scorescored
2026-05-10 08:18filter_scorescored
2026-05-10 08:12evidence_searchevidence_hunt
2026-05-10 08:06evidence_searchevidence_hunt
2026-05-10 07:54evidence_searchevidence_hunt
2026-05-10 07:48evidence_searchevidence_hunt
2026-05-10 07:42evidence_searchevidence_hunt
2026-05-10 07:36evidence_searchargument
2026-05-10 07:24audience_simulationargument
2026-05-10 07:18red_team_killargument
2026-05-10 07:12steelmanargument
2026-05-10 07:09genesisargument