Claude Opus 5.5

Decision framework

Compare cost per resolved ticket over 12 months, weighted by deflection confidence.

TICKETS, REPEAT = 400, 0.5
agent_cost   = 4000                      # monthly, fully loaded
docs_build   = 8000                      # one-off
docs_upkeep  = 500                       # monthly
deflection   = 0.35                      # % of repetitive tickets avoided

def cost(months):
    agent = agent_cost * months
    docs  = docs_build + docs_upkeep * months
    residual = TICKETS * REPEAT * (1 - deflection)   # still needs humans
    return agent, docs, residual

print(cost(12))  # (48000, 14000, 130 tickets/mo unhandled)

Rule: docs win only if deflection × repetitive volume × cost-per-ticket exceeds upkeep — and someone still handles the remainder. Docs are an asset; an agent is capacity. You likely need both eventually; sequence matters.

Missing evidence

• Ticket taxonomy: are the 200 "repetitive" tickets 5 root causes or 80?
• Handle time and current response SLA breaches
• Whether repetition signals a product defect (then fix the product)
• Who maintains docs; staleness kills deflection

Reversible first step

Tag two weeks of tickets by root cause. Write the top 3 answers as public articles, link them in replies, and measure deflection. Cost: a few hours. If deflection is below ~20%, hire instead.

Observation (what we actually have) Three customers, self-selected and unprompted, said they preferred the new onboarding. That's anecdote-level evidence: it shows the new flow is plausible and not obviously broken.

Claim (appropriately scoped) "Early qualitative feedback is positive; we have no evidence yet that the new onboarding improves activation." Not: "it's better."

What we'd need to measure

• A primary metric defined up front, e.g. % of signups completing setup within 7 days.
• Random assignment, not self-selection.
• A sample size big enough to detect the effect we care about.
• Guardrails: time-to-first-action, support tickets, 30-day retention.

from statsmodels.stats.power import NormalIndPower
from statsmodels.stats.proportion import proportion_effectsize

# baseline 40% activation, want to detect +5pp
n = NormalIndPower().solve_power(
    effect_size=proportion_effectsize(0.45, 0.40),
    alpha=0.05, power=0.8, alternative='two-sided')
print(round(n))  # ~1,500 users per arm

So: three positive comments justify continuing the experiment, not declaring a win. Ship to a randomized 50% and read out at ~1,500 per arm.

The race

Both requests run SELECT stock FROM items WHERE id=42 and read 1. Neither has written yet, so neither sees the other's intent. Each concludes "stock ≥ 1, sell it" and issues UPDATE items SET stock = stock - 1. Result: stock = -1, two customers, one item. The check and the write are not atomic — another transaction interleaves between them.

Fix 1: row-level lock (SELECT ... FOR UPDATE)

BEGIN;

SELECT stock FROM items WHERE id = 42 FOR UPDATE;  -- locks this row only
-- app checks stock >= 1, else ROLLBACK

UPDATE items SET stock = stock - 1 WHERE id = 42;
INSERT INTO orders (item_id, qty) VALUES (42, 1);

COMMIT;

The second transaction blocks on FOR UPDATE until the first commits, then re-reads stock = 0 and aborts.

Fix 2: atomic conditional update (no explicit lock)

UPDATE items
   SET stock = stock - 1
 WHERE id = 42 AND stock >= 1;

If rowcount = 0, the sale failed — roll back. Postgres locks the single row implicitly during the update.

Belt-and-braces: add CHECK (stock >= 0) on the column.