Part of the Taskly reference library — see README.md. Closes RISK-REGISTER.md R4 (founder single-point-of-failure) and R9 (no North Star / no 60-90-180 targets). Companions: BUSINESS-MODEL.md (§4 hybrid, §6 cold-start), FINANCIAL-MODEL.md (scenarios this doc's targets are calibrated to), 30-DAY-LAUNCH-PLAN.md (the outreach grind this cadence must fit around), MICROCOPY.md (tone rules for §4's canned responses), DISPUTES-AND-REFUNDS.md (authored in parallel — the escalation target for §4).
Operational, not aspirational. Everything here is either shipped in code (cited) or a manual procedure the founder can run today. The founder does everything at launch — that is the plan, not the failure. This doc makes the exit from that state explicit: measurable thresholds that retire each piece of manual work, and named triggers for the first hire.
| Manual work | The system that replaces it | Shipped? |
|---|---|---|
| Founder hand-matches every fixed-window task | FCFS auto-claim at fixed_price_cents |
Not yet — TECH-BUILD-PLAN.md B3 notes "concierge covers it now"; the accept-bid → escrow path in lib/marketplace/convert.ts is ready to reuse |
| Founder judges when a task should stop collecting offers | Hybrid lifecycle: lib/marketplace/pricing-mode.ts (FIXED_WINDOW_DAYS = 2, FLEXIBLE_WINDOW_DAYS = 5) + the app/api/cron/convert-to-fixed cron |
Shipped |
| Founder sanity-checks the locked price | fixedPriceFromOffers() — 0 offers → estimate; 1–2 → median clamped ±40%; ≥3 (MIN_OFFERS_FOR_MEDIAN) → median |
Shipped |
| Founder interviews/vouches every Tasker | /admin/providers + /admin/interviews vetting tooling (migrations 132/146/147) |
Shipped (the interview itself stays human by design) |
The transition is therefore not a rebuild — it is: build FCFS auto-claim, then flip it on pair-by-pair when the thresholds below are met.
Unit of measurement: the category × patch pair (patch = a neighbourhood-scale geo, FSA-prefix level — e.g. Cleaning × Etobicoke-North (M9V/M9W); the remote/digital lane is one Canada-wide "patch" per category). Measured weekly in the Friday scorecard, from /admin/analytics + /admin/funnels.
A pair flips from founder hand-match to FCFS auto-claim when ALL of the following hold for 2 consecutive weeks:
- ≥ 5 active Taskers in the pair (active = sent ≥1 offer or completed ≥1 task in the trailing 28 days).
- Median offers per task ≥ 3 — deliberately the same bar as
MIN_OFFERS_FOR_MEDIAN: the point where the code itself trusts the market median as a real price signal is the point where the founder stops needing to be the price/match judgment. - Fill rate ≥ 80% (share of posts receiving ≥1 offer within 24h — the same liquidity % the launch plan gates demand pushes on, §10).
Reverse rule: if a flipped pair drops below any threshold for 2 consecutive weeks, it reverts to concierge. No shame, no debate — the thresholds decide, not the mood.
Anchor exception: cooking + cleaning in the first patch (Etobicoke, near Albion Mall — BUSINESS-MODEL.md §6) stay founder-touched longest on purpose: the founder self-supplies them and they carry the review/proof engine. Expect these to be the last pairs flipped, not the first. The remote/digital lane, being liquidity-unbound, should flip first — target it as the proving ground for FCFS.
- Fixed-window tasks in the pair are claimable by any eligible Tasker at the locked price; founder stops the daily hand-match for that pair.
- Founder keeps a daily 10-minute exception sweep (any fixed task unclaimed >12h before its date → hand-match it; log it — 3+ exceptions/week = the pair reverts).
- The concierge assign tool (TECH-BUILD-PLAN "admin hand-match view") stays as the fallback path forever — it becomes the exception handler, not the default.
The 30-DAY-LAUNCH-PLAN.md daily loop (~3h outreach + content + 2h-reply SLA) is the growth engine and is protected time. Ops must fit in the boxes below or trigger §5 (delegation). Total ops budget: ≤ 3 h/day.
| Block | Time-box | What |
|---|---|---|
| Support sweep #1 (morning) | 45 min | WhatsApp (+1 437-970-7070) + care@taskly.ca + in-app flags. Canned responses (§4) first; anything novel gets a real reply and a new macro. |
| Concierge matching | 30–45 min | Hand-match every fixed-window task in un-flipped pairs (§1); confirm with both sides. Post-flip: the 10-min exception sweep. |
| Concierge Stripe onboarding | as they land (≤30 min) | Same-day WhatsApp walk-through for every newly approved Tasker — the |
| Support sweep #2 (evening) | 30 min | Clear the day's tail; nothing waits overnight that touches money or safety. |
| Scorecard tick | 5 min | Log posts / offers / fills / disputes into the weekly scorecard. |
| Slot | Time-box | What |
|---|---|---|
| Vetting interviews — Tue + Thu + Sat | 3 × 90 min (batched, ~4–6 interviews/block) | Run in /admin/providers + /admin/interviews: Stripe-Identity check, interview log, vouch. Never squeezed between DMs — batching protects both the interview quality and the outreach hours. |
| Dispute / refund block — Wed | 60 min (+ ad-hoc for urgent) | Work the /admin/disputes queue per DISPUTES-AND-REFUNDS.md. Urgent safety/damage items (alertOps fires on dispute + chargeback + safety) pre-empt everything, same day. |
| Friday scorecard + thresholds | 45 min | Fill the launch-plan §9 scorecard; check every §1.2 pair against its thresholds; check §5 delegation triggers. This is the meeting-with-yourself that replaces a standup. |
| Payout/money sweep — Fri | 20 min | /admin/payouts + /admin/chargebacks: anything stuck in escrow >72h past completion, failed transfers, refund reserve tally. |
Honest capacity check: daily ops ≈ 2–2.5 h + interviews ≈ 45 min/day averaged + weekly blocks ≈ 25 min/day averaged → ~3–3.5 h/day of ops against ~5–6 h of outreach/content/build. That is a full founder day with zero slack — which is exactly why §5's triggers are numeric, not vibes.
| Channel | SLA | Notes |
|---|---|---|
| WhatsApp +1 437-970-7070 | ≤ 2 h, waking hours (8:00–22:00) | Same bar as the launch plan's reply loop — speed is the trust signal. |
| care@taskly.ca | Same day (≤ 24 h hard) | |
| In-app assistant | Instant (automated) | lib/support/knowledge.ts powers it; feed every new macro back into it. |
| Dispute filed | Acknowledge ≤ 4 h · human decision ≤ 72 h | Per DISPUTES-AND-REFUNDS.md; alertOps already pings the founder on filing. |
| Safety incident | Immediate, pre-empts everything | /admin/safety path; see bus-factor note §6. |
Money lines always state the money's status; escrow mechanics use the locked verbatim ("held in escrow", "released when you confirm"); never "vetted", never blame, never a raw error.
- "No offers yet — is anything wrong?" → "Nothing's wrong — your post is live and Taskers usually respond soon after posting. If it's quiet by [date], it converts to a fixed price automatically, and I'll personally make sure it's covered. You're not charged anything until you accept."
- "How does paying work / is my money safe?" → "You pay only when you accept an offer, and even then the money sits held in escrow — it's released when you confirm the job's done. Nothing moves without your say-so."
- "My Tasker is late / hasn't shown." → "I'm on it — checking with them right now. Your payment is still safely in escrow; if they can't make it, you choose: we re-match you or the hold is released back, your call."
- "I need to cancel / reschedule." → "Done in a minute. Before any money has moved it's free and instant; after acceptance I'll sort it with your Tasker directly — your payment stays in escrow until it's settled."
- "The job isn't done properly." → "That's not the bar we hold. Don't release the payment — tell me what's missing and I'll have it made right or open a review. Funds stay frozen in escrow while a real person (me) looks at it. No dispute fees."
- "I'm stuck on the Stripe step." (Tasker) → "Totally normal — it's the fiddliest step. Got 10 minutes? I'll walk you through it on WhatsApp right now and you'll be payable by tonight."
- "When do I get paid?" (Tasker) → "The moment the poster confirms the job's done, your ~80% is released to your bank through Stripe — usually 1–2 business days to land. Tips are 100% yours."
- "The job turned out bigger than posted." → "Happens — don't just absorb it. Message the poster in-app with what changed and the fair add-on; if they agree we adjust before release. Never settle a difference in cash off-platform — that's what escrow is protecting you both from."
- "Who is this Tasker / how do I know they're safe?" → "Every Tasker is reviewed and approved before their first job — I interview them personally. Your calls are masked, a 4-digit door code confirms it's really them, and your money is held in escrow the whole way."
- "Something got damaged." / any safety concern → "I'm sorry — that's stressful, and it's now my top priority. Your payment is frozen in escrow as of now. Send me photos when you can; a real person (me) reviews it within the day and we follow the damage process from there." → escalate:
/admin/damage-claimsor/admin/safety, per DISPUTES-AND-REFUNDS.md.
Escalation rule: cases 5, 8, 10 — or any case where the two sides disagree about money — leave support and enter the dispute process (DISPUTES-AND-REFUNDS.md). Support's job is exhale + freeze + hand-off, never an on-the-spot money ruling in chat.
Numeric triggers, checked every Friday. Two ways to respond: fix the process (preferred first), or hire. When a trigger fires 2 Fridays running, hiring stops being optional.
| Trigger | Threshold | Response |
|---|---|---|
| Support load | > 2 h/day sustained for 2 weeks | Hire a part-time VA (~10 h/wk). First duty transferred: support triage — §3.2 macros + Stripe-onboarding walk-throughs are scripts, not judgment. |
| Interview backlog | > 10 waiting or > 5 days to interview | Add a 4th weekly interview block first; if still breached, the VA takes scheduling/pre-screening (ID + Stripe-Identity check) — the interview itself stays with the founder (the "personally interviewed by our founder" promise on the homepage is load-bearing; delegating it is a brand decision, not an ops one). |
| SLA breaches | 2-h WhatsApp SLA missed on 3+ days in a week | Same VA response as support load. |
| Concierge matching | > 45 min/day for 2 weeks with no pair near its §1.2 flip | Prioritize the FCFS build (TECH-BUILD-PLAN B3) over new features — this trigger buys engineering, not headcount. |
| Dispute volume | > 3 open disputes at once, twice in a month | Bring the refund-reserve % decision (RISK-REGISTER R24) to a head; disputes themselves are never delegated first — money judgment + pattern-spotting is founder work longest. |
Order of transfer (locked): 1) support triage + Stripe concierge → 2) interview scheduling/pre-screen → 3) content/proof-card production (already creator-shared per the launch plan) → 4) concierge matching (only to a system, §1, not to a person) → last) interviews and disputes.
Budget note: a 10 h/wk VA at ~$20/h ≈ $800/mo — roughly the entire floor-scenario monthly contribution (FINANCIAL-MODEL.md §6). At floor scale the correct response to most triggers is process + FCFS, not headcount; the VA becomes affordable between base and stretch. The triggers stand anyway — if they fire at floor scale, that is a signal the model needs the hire and the growth to pay for it.
- Credentials vault (do this week, ~1 h): password manager vault holding Supabase, Stripe, Vercel/hosting, domain/DNS, Resend, Twilio, Groq, Google (GBP + GA4 + Search Console), social accounts, and the
.envsecret set (SUPABASE_SERVICE_ROLE_KEY,STRIPE_WEBHOOK_SECRET,CRON_SECRET, …). One trusted emergency contact holds recovery access. - Second admin: a second
profiles.role = 'admin'account exists, credentialed in the vault — so admin access doesn't die with one login. - A one-page "how money moves" note in the vault: escrow capture → release; where refunds are issued (Stripe dashboard); the
cron/auto-release-escrowjob andCRON_SECRET. - If the founder is unreachable 48 h: the platform degrades safely, not catastrophically — escrow auto-release keeps completed jobs paying out (
app/api/cron/auto-release-escrow), posts still convert to fixed via cron, and nothing charges a customer without their acceptance. The emergency contact's only jobs: post a WhatsApp/status auto-reply ("replies are slower than usual — your money is safe in escrow and nothing moves without you"), pause new hand-matched promises, and freeze any open dispute in place (funds already frozen by default). No new vetting, no new refunds, no new categories — the system holds; growth pauses.
Why this one, argued against the alternatives:
- vs GMV: GMV is a multiplier on completed tasks and is distorted by ticket mix — three $350 cleans can mask a dead marketplace. FINANCIAL-MODEL §7 is explicit: completed-paid-job volume is the most sensitive input in the entire model; GMV is derived from it, not the other way round.
- vs posts: a post with no offer earns $0 and permanently loses the customer (MARKET-VIABILITY §3). Posts are a funnel input, not value delivered.
- vs Taskers onboarded: supply that never transacts is a vetting cost (the §1c vetting trap), not progress.
- A completed paid task is the only event where both sides got what they came for, money actually moved, escrow did its job, and a review/repeat/referral becomes possible. It contains liquidity × conversion × supply health in one integer, it's countable daily with zero ambiguity, and every §1.2 threshold and §5 trigger ultimately serves it. Weekly (not monthly) because at cold-start scale a month hides two bad weeks.
Calibrated to FINANCIAL-MODEL §6 (floor ≈ 40 jobs/mo, base ≈ 65, stretch ≈ 140): 60-day ≈ between floor and base; 90-day ≈ base; 180-day ≈ base-to-stretch. These are honest cold-start numbers — small on purpose. Miss the floor two periods running → the §1/§5 machinery is not the problem; liquidity is; go back to the launch plan's supply loop.
| Metric | 60-day | 90-day | 180-day | Read where |
|---|---|---|---|---|
| North Star: completed paid tasks / week | 10–15 | 15–25 | 35–50 | /admin/analytics (bookings by status/week) |
| GMV / month | $6–9k | $10–14k | $20–28k | /admin/analytics (money columns are cents — divide by 100) |
| Liquidity: median offers per task | 1–2 | 2–3 | ≥ 3 (the §1.2 flip bar) | /admin/funnels + task_bids counts |
| Fill rate (posts with ≥1 offer, 24h) | ≥ 70% | ≥ 80% | ≥ 85% | Weekly scorecard (launch-plan §9 tracks it already) |
| Repeat-poster rate (2nd task ≤ 60 days) | ~15–20% | ~25–30% | ~35–40% (recurring-weighted — the LTV lever, FINANCIAL-MODEL §5) | /admin/customers cohort pull |
| Tasker weekly actives (≥1 offer/wk) | 12–18 | 20–30 | 40–60 | /admin/providers + offers/wk |
| Flipped FCFS pairs (§1.2) | 0 | 1 (remote lane) | 3–5 | The Friday threshold check |
Instrumentation honesty: /admin/analytics, /admin/funnels, /admin/traffic, /admin/utm and GA4 (GA_PROPERTY_ID) exist and cover most reads; median offers/task, repeat-poster cohort, and per-pair actives are today a weekly manual query, not a dashboard tile. That manual pull is ≤30 min of the Friday block — acceptable at this scale; add tiles only when the pull exceeds the time-box.
v1 · 2026-07-18. Review the thresholds (§1.2) and targets (§6.2) at each 30-day mark — change them by writing a new number and a dated reason, never silently.