Back to blog

How to stop being the bottleneck: an API-first playbook to delegate customer decisions

June 18, 2026

You’re answering refund requests at 10pm, approving a $12k vendor invoice between calls, and still the hiring screen for every new candidate lands in your inbox. That pattern feels inevitable until you treat those moments as decisions you can encode, not tasks you must perform. Enter the decision proxy: a system that represents your judgment via API, evaluates requests against your policies, precedents, and memory, and either executes, drafts, or escalates with an auditable rationale.

What a decision proxy does (and why an API-first one matters)

“Decision proxy” is the working keyword here. It’s not a bot that acts on its own, and it’s not a rigid rules engine. It’s an API you call with a plain-language request. The proxy consults your stored context — policies, precedents, templates, entities, and an auto-generated memory — weights signals by relevance and freshness, and returns a structured outcome: execute, draft, or escalate, plus a confidence score and an audit link.

An API-first design matters because founders and engineers live in code. You can embed decision calls into email workflows, webhooks from your support tool, or a Slack bot that catches inbound partnership asks. That removes manual copy-paste, ensures every decision is auditable, and keeps the loop fast.

Practical playbook: three-week rollout to stop being the bottleneck

The goal: move repeatable customer-facing and operational decisions off your plate quickly, safely, and measurably. This is not a theoretical checklist. These are the exact steps you can run in 21 days.

1. Map the decision surface, day 0–2. List every decision you personally handle: refunds, scope approvals, vendor spend >$X, interview screens, partner yes/no. Capture who requests them, the trigger, and the current response rules you use. If it’s easier, pick the 6–8 highest-frequency items that cost you the most context-switch time.
2. Codify policies and precedents, day 3–7. Turn the rules you already use into two things: (a) hard policies (non-negotiables) and (b) precedents (past decisions with rationale). Policies are simple: thresholds, required approvals, disqualification rules. Precedents are short narratives: the request, your decision, why you chose it, outcome. Time-box this: you don’t need legal prose; 3–6 clear policies plus 10–20 precedents cover most cases.
3. Pin confidence thresholds and playbooks, day 8–10. Configure the workspace to escalate when confidence is low or a policy would be violated. Decide your default: do you want drafts for the team to review, or immediate execute for low-risk items? Use a conservative default the first week and widen as you see reliable behavior.
4. Run dry runs and simulate historical decisions, day 11–14. Replay the last 30–60 decisions through the proxy in dry-run mode. Compare outcomes to what you did and note mismatches. This is the fastest way to find missing context and to tune staleness windows.
5. Go live with a narrow auto-reply and audit, day 15–21. Start with automated drafts saved to your outbox or auto-reply with a 10-minute delay. Keep an audit link in every outgoing reply. Track autonomy rate (percent of requests returned as execute), escalation rate, average confidence, and override rate.

What to measure (and target)

Track four metrics weekly: autonomous rate, escalation rate, average confidence, and override rate by category. A reasonable early target is to remove 50–70% of founder-handled decisions within 60 days while keeping escalation under 20% for new categories. Use these numbers as a learning signal, not a promise — your business mix and risk tolerance determine the right thresholds.

Measure downstream impact too. If you route customer decisions, watch NPS and time-to-resolution. For lead qualification, compare MQL-to-SQL conversion by source. High-intent content and tighter qualification lift the whole pipeline; marketing teams now push MOFU/BOFU content because it produces more SQLs. That same discipline applies to automated decisioning: the playbook that produces better-quality outcomes reduces churn, not just your inbox.

How to keep risk low

• Flag policies as potentially stale after 365 days and precedents after 180 days. When stale context influenced a decision, surface it in the audit and reduce confidence.
• Require minimum context for high-risk executes — invoice approvals over $X must include vendor contract ID and PO number.
• Use Judgment Coaching: when the system hits low confidence, run short calibration sessions so the model learns your corrections quickly.

This combination of freshness controls, explicit escalation triggers, and a tight feedback loop from overrides converts early friction into durable autonomy.

Example integration and next step

Embed decision calls where decisions arrive. For example, have your support tool post a plain-language request to the decision endpoint, consult pinned context, and return a drafted reply. If you want to test quickly, run a dry-run of the last 30 refunds through the API and compare outcomes. If you’re ready to try one category, the Quickstart docs show how to POST a request and pin context: see the quickstart and context guides.

If you want less friction: pick refunds or vendor approvals first. They’re frequent, structured, and have clear numeric thresholds. If you want faster wins, pick a decision with a small, high-frequency impact — you’ll reclaim time immediately and have lots of precedents to tune the proxy.

You don’t need to hire an EA or build an internal rules engine. You need a system that represents your judgment, learns from it, and hands you only the things that truly require you. That’s the point of a decision proxy. When you're ready, start with the quickstart and run a 14-day dry-run on the one decision you dread the most.

Quickstart • Use cases • Pricing