Varpet — Service Provider Flow: Blue vs Green Team

📘 Provider Model — Two Types, One Marketplace

🔵

Blue Team — Individual Provider

Solo operator. Independent contractor. No company above them. Bids directly on marketplace jobs. Gets paid directly via their own Stripe Connect account. Client tracks them immediately after bid is accepted.

DB: providers.provider_type = 'individual'

🟢

Green Team — Team Provider

Employee or member of a B2B company account. Their company may bid on their behalf (admin dispatches), or they can bid directly under the company umbrella. Payment goes to company Stripe Connect. Client tracks the person, not the company.

DB: providers.provider_type = 'team' + account_providers link

Plan A ($1,500/mo) and Plan B (15%/job) are pricing tiers for B2B accounts — they are NOT provider types. A Green Team company can be on Plan A or Plan B. Blue Team individuals always pay 15%/job (no flat rate option at launch).

End-to-End Flow — Master Overview

👤

Client Logs In

Searches available services in their city/ZIP

📋

Submits Service Request

Category, location, description — open bid

🖥️

Master Admin Panel Receives Request

Routing engine: trade + ZIP + account_providers lookup

📣

Open Bid Broadcast

All B2B companies + their employees in this trade/ZIP receive the job

🟢 Green Team — Via Company

🏢

B2B Company Admin Bids

Reviews request, submits company bid

✅

Client Accepts Company Bid

Job assigned to company account

👥

Company Dispatches Employee

Admin assigns specific employee from their roster

📍

Client Tracks Employee

GPS + status — the worker, not the company brand

🏁

Job Complete

Sign-off → payout release → review

🔵 Blue Team — Direct Individual

🧑‍🔧

Employee Bids Directly

Individual provider (company employee) bids under company umbrella

✅

Client Accepts Employee Bid

Provider profile shown to client immediately

📍

Client Tracks Employee

Same GPS tracking — direct from accepted bid

🏁

Job Complete

Sign-off → payout release → review

⚡ Key Architecture Point for Grigori

In both bid routes, the client always tracks the individual worker — not a company brand. Whether a company dispatches the employee (Company Bid Route) or the employee wins the bid directly (Employee Direct Bid), the tracking object is the same: a provider record with GPS, trust score, and job status. The only difference is whether the dispatch decision was made by the company admin or by the employee themselves.

Every provider in the US B2B build is linked to a B2B account via the account_providers join table. There are no unaffiliated standalone freelancers in this model.

Client Journey — Step by Step

1

Client creates account and logs in to Varpet app or web

Profile: name, city/ZIP, service preferences, payment method on file (Stripe)
2

Client browses service categories available in their ZIP code

Filters: trade/category, date/time preference, budget range. Only shows services where active B2B companies operate in their ZIP.
3

Client submits a service request — open bid model

Fields: description, preferred date/time, location, photos (optional), budget (optional). Request is visible to all qualified providers in that trade/ZIP.
4

Platform routing engine broadcasts the open bid

Admin panel queries account_providers: finds all B2B companies + employees with matching trade and ZIP. Notification sent to company admins AND eligible employees. Client waits for bids — they do NOT see internal routing.
5

Client receives one or more bids — reviews and selects

Each bid shows: provider name, trade, trust score, price, ETA, verification badges. Could be a company bid (admin submitted) or an employee direct bid. Client cannot see the difference — they just see a named, rated provider.
6

Client accepts bid — job is created and locked in the system

If company bid was accepted: company admin receives notification → assigns specific employee from roster → employee profile is revealed to client.
If employee direct bid was accepted: that provider's profile is already revealed — no extra dispatch step needed.
7

Client tracks the assigned provider in real-time

GPS tracking shows the actual worker. Status updates: Confirmed → On the Way → Arrived → Working → Done. The client always tracks a person, never just a company name.
8

Job completed → digital sign-off → payment released → review prompt

Client signs off digitally (mobile). Approved payout releases through Stripe Connect. Review is tied to the individual worker's trust score profile. Rating affects their composite score.

⚠️ Grigori — Bid Presentation Note

Whether the bid comes from a company admin or an employee directly, the client-facing bid card must look identical — a named, rated person with a trust score. The internal routing difference is transparent to the client. This keeps the UX clean and consistent regardless of which bid route wins.

Admin Routing Engine — How Jobs Are Broadcast

📌 Routing Principle

The routing engine does not prioritize individual providers over companies (or vice versa). All providers affiliated with B2B accounts in the matching trade/ZIP are notified simultaneously. The open bid model lets the market decide who wins — fastest/best bid from any eligible source.

R1

Client request lands in Master Admin Queue

Fields logged: trade, ZIP, description, client_id, created_at, bid_deadline (configurable, e.g. 30 minutes)
R2

Routing query: find all active providers in trade + ZIP

SELECT p.* FROM providers p JOIN account_providers ap ON ap.provider_id = p.id WHERE p.trade = :trade AND :zip = ANY(p.zip_codes) AND ap.status = 'active' AND p.active = true
R3

Bid broadcast — two channels fire simultaneously

Channel A: Notify b2b_admin users of each matched account (company-level bid opportunity).
Channel B: Notify individual provider users (employees) whose ZIP + trade match (employee direct bid opportunity).
R4

Bid window open — multiple bids can arrive

Platform collects bids. Each bid contains: provider_id (or company account + proposed employee), price, ETA, message. Ranked by trust score + ETA for client presentation.
R5

Client selects winning bid

Job status updates to assigned. All other bidders are notified the job is closed. Stripe payment workflow begins.
R6

Post-assignment routing branch

If company bid won: company admin must assign a specific employee within [X minutes] or job escalates back to admin.
If employee direct bid won: no further assignment step. Provider is already confirmed. Client tracking activates immediately.
R7

No-bid escalation (fallback)

If bid window closes with no bids received: job escalates to Varpet admin for manual handling. Client is notified of delay. Job stays open until assigned.

⚠️ Company Dispatch SLA

After a company bid is accepted, the company admin must assign an employee within the SLA window (recommend 15 min). If they don't, the job should auto-escalate. Build a countdown timer in the company admin view.

✅ Trust Score in Routing

When presenting bids to the client, sort by: (1) trust score, (2) ETA, (3) price. High trust score providers surface first — this is the platform's quality signal and moat.

🟢 Green Team — B2B Company Bids, Then Dispatches Their Provider

Green Team Provider belongs to a B2B company. Company admin receives the job, submits the bid, then assigns the specific team member. provider_type = 'team'

1

B2B company admin sees the open bid in their dashboard

Notification via Twilio SMS + in-app alert. Shows: client description, ZIP, trade, bid deadline.
2

Company admin reviews their available employees for this job

Admin sees their roster (account_providers → providers). Filters: trade, ZIP coverage, current availability, trust score. Admin mentally pre-selects the employee before bidding.
3

Company admin submits company bid

Bid fields: price, ETA, brief message. The company's name + aggregate trust score is shown to the client. The specific employee is NOT revealed at this stage.
4

Client accepts company bid — job locked to this account

Job status: assigned_to_account. Payment workflow begins. Company receives immediate notification to dispatch.
5

Company admin assigns a specific employee to the job

Admin opens job → selects employee from their roster → confirms dispatch. Employee must be an active provider in account_providers with matching trade. Job status → dispatched.
6

Employee (provider) receives job assignment notification

SMS + in-app push. Shows: client address, job description, ETA expectation, and payment amount. Employee must acknowledge acceptance.
7

Employee's provider profile is revealed to the client

Client now sees: employee name, photo, trust score, verification badges, GPS location. Client tracking activates. This is the same profile view as an employee direct bid — the handoff is invisible to the client.
8

Employee arrives, performs service, requests digital sign-off

Client signs via mobile. Photos uploaded (before/after). Job status → complete.
9

Approved payout releases to company's Stripe Connect account

Company is the payment recipient (not the employee directly). Company handles their own payroll to the employee. Review triggers — tied to the employee's trust score, not the company account.

🏗️ DB Objects Involved

b2b_accounts (company entity) → account_providers (join: which employees belong to this company) → providers (the employee record: GPS, trust_score, trade, zip_codes) → jobs (b2b_account_id + provider_id + client_id + payment_status)

⚠️ Important — Commission Rules

Jobs dispatched through the marketplace (client submitted → company bid → won) are subject to Varpet commission per the B2B account's pricing plan: Plan A accounts pay $1,500/mo flat (no per-job fee). Plan B accounts pay 15% deducted from each completed paid job through the Stripe Connect payment flow. The job source field determines this: jobs.job_source = 'marketplace'.

🔵 Blue Team — Individual Provider Bids Directly

Blue Team Solo operator. No company above them. Bids directly, gets paid directly. provider_type = 'individual'

📌 How Blue Team Differs from Green Team

A Blue Team provider is a solo operator — a single person running their own trade business. They have no company admin dispatching them. They see the open bid, submit their own bid with their own price and ETA, and if accepted, the client tracks them directly. Their Stripe Connect account receives payment minus Varpet's 15%. No middleman, no dispatch step, no company layer. Simple and fast.

1

Employee (provider user) receives open bid notification

Same notification channel as company admins. Employee's app shows available jobs matching their trade + ZIP. Role: provider with company_id pointing to their B2B account.
2

Employee reviews the job request and decides to bid

Employee sees: description, location, budget range, preferred timing. They set their own price + ETA in the bid. Their personal trust score is attached to the bid automatically.
3

Employee submits bid — their provider profile is shown to the client

Client sees: employee name, trade, trust score, verification badges (ID verified, background check, insurance), price, ETA. The company name may or may not be shown (UI decision) — but the client evaluates the individual worker.
4

Client accepts the employee's bid

Job status → assigned. Provider ID is written directly to jobs.provider_id. No intermediate company dispatch step. Payment workflow begins immediately.
5

Employee confirms the job and GPS tracking activates

Client sees employee location in real-time. Status flow: confirmed → on_the_way → arrived → working → complete. Employee updates status from their mobile app.
6

Service performed — employee requests digital sign-off

Photos uploaded. Client signs off. Job status → complete.
7

Approved payout releases to the provider's Stripe Connect account

Same payment flow as company route — the B2B account receives the funds. Internal employee payroll is managed by the company outside Varpet. Review is tied to the employee's personal trust score.

✅ Client Experience — Identical

From the client's perspective, an employee direct bid looks exactly the same as a company bid that was dispatched to a worker. They always see a named, rated, GPS-trackable individual. The route taken is invisible.

⚠️ Grigori — Company Awareness

When an employee bids directly, should the company admin see this in their dashboard? Recommend yes — the company admin should have a log of all bids submitted by their employees, even if they didn't initiate the dispatch. Visibility without blocking.

B2B Own-Customer Panel — Zero Commission Track

Own Customer B2B company adds their existing customers to the platform and manages jobs internally. No Varpet commission applies.

📌 Purpose — Why This Exists

Many local service companies already have an existing customer base they service directly. Forcing them to run these jobs through the Varpet marketplace (and pay commission) would be a deal-breaker. The Own-Customer Panel lets them use Varpet's dispatch, tracking, and payment tools for their existing relationships — at no extra cost. This is a value add that drives stickiness, not a revenue source. It also naturally expands the platform's job volume and trust score data.

Flow — Own-Customer Job

1

B2B company admin adds their existing customer to the platform

Admin creates a client record: name, address, contact, service history (optional). clients.b2b_account_id = this_company. Client is tagged as client_source = 'own_customer'.
2

Company admin creates a job directly — no open bid

Job is created with job_source = 'own_customer'. This flag bypasses the marketplace routing engine. No broadcast. No competing bids. Direct assignment only.
3

Company admin assigns the job to one of their employees

Same assignment UI as the company bid route — select from roster. Employee receives notification and confirms.
4

Employee performs service — client tracks via Varpet app

If the own-customer has the Varpet app, they get GPS tracking + status updates. If not, the company admin can share a tracking link manually.
5

Job complete — payment handled directly by the company

Varpet takes zero commission on own-customer jobs. Payment may go through Stripe (if configured) or be handled outside the platform. Payout-release rules are optional for own-customer jobs.

✅ Benefits to the Company

Full dispatch and tracking tools at no extra cost. All jobs — marketplace AND own-customer — visible in one dashboard. Trust score data accrues across both job types, strengthening the employee's profile over time.

⚠️ DB Flag Required

The jobs.job_source field is critical. It must be enforced at the DB level to prevent billing logic from applying commission to own-customer jobs. Recommend: ENUM('marketplace', 'own_customer', 'manual'). Commission triggers only on 'marketplace'.

Future: Own-Customer → Marketplace Conversion

When an own-customer later searches Varpet for a service that the company doesn't offer, the platform can surface other B2B providers — naturally converting an own-customer into a marketplace transaction. This is a growth flywheel: companies bring their customers in, and Varpet earns commission when those customers go outside the company's service scope.

Three Provider Tracks — Side-by-Side Comparison

Dimension	🟢 Green Team (B2B Company)	🔵 Blue Team (Individual)	B2B Own-Customer Panel
Job origin	Client submits via marketplace	Client submits via marketplace	Company admin creates directly
Who bids	Company admin (on behalf of company)	Individual employee (under company umbrella)	No bid — direct assignment
Dispatch step after bid wins	✓ Admin must assign employee	✗ Employee already confirmed	✓ Admin assigns employee
Client tracking object	Employee (after company assigns)	Employee (immediately)	Employee (after assignment)
Client sees company name	Yes — company bid card shown	Optional — employee shown primarily	N/A — direct company relationship
Trust score used	Company aggregate + employee after assign	Employee personal trust score	Employee personal trust score
Varpet commission	Yes — per Plan A/B pricing	Yes — per Plan A/B pricing	✗ Zero commission
Stripe payment + payout release	Yes — required	Yes — required	Optional (company handles payment)
Review tied to	Employee trust score profile	Employee trust score profile	Employee trust score profile
DB `job_source` value	`'marketplace'`	`'marketplace'`	`'own_customer'`
Open bid broadcast	✓ Yes	✓ Yes	✗ No — internal only
Who can initiate	Company admin (b2b_admin role)	Employee (provider role)	Company admin (b2b_admin role)
Plan A/B pricing applies	✓ Yes	✓ Yes	✗ No

Pricing Plans — Plan A vs Plan B (for reference)

Plan A

$1,500/mo

Flat monthly subscription — best for accounts ready to scale

Managed Google Ads integration
CallRail tracking number per account
Website lead webhook to jobs table
Metricool social feed
Unlimited marketplace jobs — no per-job fee
Full dispatch + payment protection + trust score
B2B own-customer panel included

Plan B

15% per completed job

Zero upfront — 15% deducted from each completed paid job via Stripe Connect

No monthly commitment
Dispatch + payment protection + trust score included
B2B own-customer panel included
Natural upsell: once job volume makes $1,500/mo the cheaper option, upgrade to Plan A
15% deducted automatically at job completion (Stripe Connect)

⚠️ Plan A/B = Pricing Only — Not Provider Types

Plan A and Plan B describe the B2B account's subscription pricing tier — not the type of provider or the routing path. Any B2B account on any pricing plan can use Company Bid, Employee Direct Bid, or the Own-Customer Panel. The plan determines how Varpet bills the account, nothing else.

Database Architecture — Key Tables & Relationships

📌 Schema Source

Based on: VARPET Migration account_providers 2026 0505.sql and VARPET Lovable Prompt Provider Management 2026 0505.md. Supabase project: ocmfkyeziebaspxydbei.supabase.co. RLS enforced at Postgres level — not application code.

📋 providers — Global Pool (Blue + Green)

Field	Type	Notes
id	UUID	Primary key
provider_type	ENUM	'individual' (🔵 Blue — solo, no company) \| 'team' (🟢 Green — belongs to a B2B account via account_providers)
name	TEXT	Full name of the worker/provider
email	TEXT	Login / contact
phone	TEXT	Twilio SMS target
trade	ENUM	handyman, plumbing, electrical, hvac, auto_body, painting, cleaning, other
zip_codes	TEXT[]	Array of ZIPs this provider serves — used in routing query
trust_score	NUMERIC(5,2)	0–100 composite score (7-component). Default 70.0 for new providers.
verified	BOOLEAN	Identity verified
background_check	BOOLEAN	Background check passed
insurance_verified	BOOLEAN	Proof of insurance on file
tier	ENUM	'standard' \| 'preferred' \| 'elite' — NOT Plan A/B
stripe_id	TEXT	Stripe Connect sub-account (if employee receives direct pay — TBD)
language	TEXT	Primary language (for future VOICEN integration)
active	BOOLEAN	Soft-disable without deleting the record

🔗 account_providers — Join Table (Provider ↔ B2B Account)

Field	Type	Notes
account_id	UUID	FK → b2b_accounts.id (CASCADE delete)
provider_id	UUID	FK → providers.id (CASCADE delete)
status	TEXT	'active' \| 'suspended' \| 'removed'. Only 'active' providers receive bid notifications.
added_by	UUID	user_profiles.id of the admin who added this provider
added_at	TIMESTAMPTZ	Auto-set NOW()
PRIMARY KEY (account_id, provider_id) — a provider can be linked to approved B2B accounts according to employment or contractor rules.

RLS Policies: founder_all_account_providers (full access) · b2b_own_account_providers (account-scoped) · provider_own_account_memberships (SELECT only, own provider_id)

🏢 b2b_accounts — Local Service Business Accounts

Field	Type	Notes
id	UUID	Primary key
company_name	TEXT	e.g. "CaliforniaFix Auto Body"
contract_tier	TEXT	'plan_a' \| 'plan_b' — B2B pricing plan selection
monthly_cap	NUMERIC	Optional job cap for Plan A accounts
contact_email	TEXT	Primary admin contact
stripe_connect_id	TEXT	Company's Stripe Connect account — approved payouts release here

👤 clients — End Customers

Field	Type	Notes
id	UUID	Primary key (= auth.uid() for marketplace clients)
name	TEXT	Full name
b2b_account_id	UUID	FK → b2b_accounts. Set for own-customer records; NULL for marketplace clients.
type	ENUM	'marketplace' \| 'own_customer'
kyc_level	INT	For future compliance requirements
stripe_customer_id	TEXT	Stripe customer for payment method on file
RLS Policies: `founder_all_clients` · `b2b_own_clients` (b2b_account_id scoped) · `client_own_record` (id = auth.uid())

🔧 jobs — Core Transaction Table

Field	Type	Notes
id	UUID	Primary key
trade	ENUM	Matches providers.trade
zip	TEXT	Service location ZIP
status	ENUM	pending \| assigned_to_account \| dispatched \| in_progress \| complete \| disputed
provider_id	UUID	FK → providers. The EMPLOYEE assigned, not the company account.
client_id	UUID	FK → clients
b2b_account_id	UUID	FK → b2b_accounts. Always set, even for direct employee bids.
job_source	ENUM	'marketplace' (commission applies) \| 'own_customer' (no commission) \| 'manual'
bid_type	ENUM	'company_bid' \| 'employee_direct_bid' — tracks which route was used
payment_status	ENUM	pending \| collected \| payout_released \| refunded
payment_amount	NUMERIC	Customer payment amount processed through Stripe
photos	TEXT[]	Before/during/after URLs
scope_doc	TEXT	Job description / scope
sign_off	BOOLEAN	Digital sign-off by client. Triggers approved payout release.
created_at	TIMESTAMPTZ	Auto NOW()

🌍 country_operations — Country Ownership / Licensing Layer (NEW)

Field	Type	Notes
id	UUID	Primary key
country_code	TEXT	'AM' (Armenia), 'BE' (Belgium), 'US' (USA) — ISO 3166 code
country_name	TEXT	e.g. 'Armenia', 'Belgium', 'USA'
operation_type	ENUM	'company_owned' \| 'licensed_operator' \| 'to_confirm'
operator_legal_name	TEXT	Varpet entity or independent licensed territory operator
platform_royalty_pct	NUMERIC	7% proposed only for licensed_operator; NULL for company-owned markets
royalty_base	TEXT	Defined local platform gross revenue; exclusions set by agreement
currency	TEXT	Local currency code: 'USD', 'EUR', 'AMD'
payment_provider	TEXT	Local payment rail (Stripe, IDram, etc.)
status	TEXT	'active' \| 'pending' \| 'suspended'. Active: AM, BE. Launching: US.
admin_user_id	UUID	FK → user_profiles. Independent country_admin for either operation model.

Country operations: 🇦🇲 Armenia — ACTIVE, model to confirm · 🇧🇪 Belgium — ACTIVE, model to confirm · 🇺🇸 USA — COMPANY-OWNED PILOT

👥 user_profiles — Roles (RLS Gate)

Role	Who	What they see
`global_admin`	Captain (Varpet Global)	Permitted oversight across country operations, accounts, providers, jobs, and licensed-market royalty reports.
`country_admin`	Country Operation Admin	Their country only — whether Varpet-owned or licensed. Manages local B2B accounts, providers, jobs, and compliance.
`b2b_admin`	Company corporate admin	Their account's providers (via account_providers), their jobs, their marketing dashboard. Scoped by country.
`b2b_user`	Business location user	Same as b2b_admin but limited to one location. Read-only on provider verification.
`provider`	🔵 Blue or 🟢 Green Team worker	Their assigned jobs only. No marketing data. Mobile-first job card view.

🌍 Two Separate Money Rules — Do Not Combine Them

15%

B2B Plan B charge for completed marketplace jobs inside a country

Licensed country operator royalty to Varpet Global on defined local platform revenue

Royalty between Varpet Global and a company-owned country such as the US pilot

Plan A/B pricing governs what a local B2B customer pays. Country licensing governs what an independent licensed territory operator owes Varpet Global. The 7% royalty is not a provider payout split and must be applied only when country_operations.operation_type = 'licensed_operator'.

🌍 VARPET GLOBAL ADMIN

Platform Overview — All Countries

global_admin ● No RLS Filter — Full Access

Countries

2 Active · 1 Launching

Providers

4,795

Verified platform-wide

Total Jobs

47,193

Completed all-time

Platform GMV

$1.41M

Cumulative all-time

Commission Rate

15%

Plan B · marketplace jobs

Country Operations — country_operations

Country	Operator	Status	Currency	Payment Rail	Model	Global Royalty	Admin Role
🇦🇲 Armenia code: AM	Varpet Armenia	● ACTIVE	AMD ֏	Stripe · IDram	Confirm	Per agreement	`country_admin (AM)`
🇧🇪 Belgium code: BE	Varpet Belgium	● ACTIVE	EUR €	Stripe · Bancontact	Confirm	Per agreement	`country_admin (BE)`
🇺🇸 USA code: US	Varpet USA	◐ LAUNCHING	USD $	Stripe Connect	Company-owned	N/A	`country_admin (US)`

Country Intelligence Boards — Live Dashboards

🇦🇲

Armenia

✅ Real Data · Company-Owned

→ Open Armenia Intel Board

🇧🇪

Belgium

🔑 Licensed · Roof Care · 7% Royalty

→ Open Belgium Intel Board

⭐ ACTIVE FRANCHISE PILOT

🇺🇸

USA — Company Owned

🚀 Launching 2026 · CaliforniaFix Pilot · LA First

Franchise → B2B

Admin manages all accounts

$1,500/mo

Flat fee per B2B account

⚙️ Open Admin Portal → USA Intel Board

Access Hierarchy — Who Sees What

🌍

⚓ Captain — global_admin

All countries · All accounts · All providers · All jobs · All revenue · No RLS filter

🇦🇲

country_admin (AM)

Independent panel · Model to confirm

b2b_admin (AM)

Local company accounts

🟢 Green Team · 🔵 Blue Team

4,795 providers

🇧🇪

country_admin (BE)

Independent panel · Model to confirm

b2b_admin (BE)

Local company accounts

🟢 Green Team · 🔵 Blue Team

Local providers

🇺🇸

country_admin (US)

COMPANY-OWNED PILOT · CaliforniaFix

⚙️ b2b_admin (US)

→ Open Admin Portal

🟢 Green Team · 🔵 Blue Team

US service providers

Local Pricing vs Country Licensing

Local Marketplace Payment Flow

Client pays 100% → payment collected through Stripe

Digital sign-off → provider payout follows the local job agreement

Plan B → 15% platform fee on completed marketplace jobs

Plan A → $1,500/mo local B2B fee; no per-job platform fee

Plan B — Per Job

15%

Local platform fee

B2B

local pricing

Job

marketplace

Licensed Country Operator

royalty to Varpet Global

Calculated on defined local platform gross revenue
Does not apply to company-owned US pilot

Do not combine fee layers: Plan A/B governs local B2B customer pricing. A country royalty exists only for an independent licensed operator and is stored in country_operations.platform_royalty_pct. Royalty base and exclusions must be written in the licensing agreement.

🤖 PHASE 2 — AI LAYER

3-Agent AI Architecture

Customer Agent · Provider Agent · Admin Orchestrator — each owns its lane, talks to each other

Claude Haiku 4.5

~$0.002 / interaction · Zero new vendors

"Three AI agents working in parallel — one handles your clients, one handles your workers, one manages everything in between. From first call to five-star review, fully automated."

🧑‍💼

Customer Agent

Talks to: End Client

What it handles

📞 Inbound lead → qualify → create job

📵 Missed call → auto SMS in 60s

📍 "Marcus assigned. ETA 45 min."

🚗 "Your provider is on the way."

✅ "Job done. Sign off: [link]"

⭐ Rating collection + Google review

🔁 +7 day rebooking SMS

Does NOT

Contact providers · Dispatch jobs · See other clients

customer-agent

Triggered by: Twilio · CallRail · Form POST · Supabase Realtime

🔧

Provider Agent

Talks to: 🔵 Blue + 🟢 Green Team

What it handles

📤 "New job: [trade] [ZIP]. Accept?"

✅ Confirm: client details + address

⏰ 60-min arrival reminder

📷 Photo upload prompts (before/after)

🏁 "Mark complete to release payment."

💰 "$X released to your Stripe."

🎯 Trust score change notification

Does NOT

Contact clients directly · Dispatch jobs · See other providers

provider-agent

Triggered by: Twilio inbound · Supabase Realtime · Scheduled reminders

🧠

Admin Orchestrator

The Brain — coordinates both agents

What it handles

🎯 Dispatch: match provider by trade/ZIP/trust

🔄 Status relay: Provider → Customer Agent

⚠️ Escalate: no accept → retry → alert admin

💳 Stripe payout release after sign-off

📊 Local B2B pricing + licensed-market royalty reported separately

📈 Daily/weekly reports to admins

🚨 Low rating → flag provider + alert

Does NOT

Talk to clients · Talk to providers · Skip escalation

admin-agent

Triggered by: Customer Agent events · Provider Agent events · Stripe webhooks · Cron

Inter-Agent Communication Flow

── LEAD PHASE ──
CLIENT contacts → Customer Agent qualifies + creates job → signals Admin Agent
↓
Admin Agent matches provider → signals Provider Agent
↓
Provider Agent sends job offer → provider accepts → reports to Admin Agent
↓
Admin Agent sets jobs.status = 'assigned' → Supabase Realtime fires
↓
Customer Agent picks up Realtime → SMS client: "Marcus assigned. ETA 45 min."
── IN-JOB PHASE ──
Provider Agent (arrives/completes) → Admin Agent → Customer Agent (client update)
Customer Agent (sign-off received) → Admin Agent (Stripe release) → Provider Agent (payment notice)
Customer Agent (rating collected) → Admin Agent (trust score update + escalate if <3★)

      Key rule: Provider Agent NEVER contacts client. Customer Agent NEVER contacts provider. Admin Agent is the only relay.
    

Build Sequence — Grigori

Phase 2A · 3 wks · FIRST

Admin Agent

Dispatch logic · Status relay · Escalation rules · Stripe release · Revenue split

Phase 2B · 3 wks

Provider Agent

Job offer SMS · Status updates · Photo prompts · Payment confirmation

Phase 2C · 3 wks

Customer Agent

Lead qualify · Status updates · Sign-off · Rating · Rebooking

Phase 2D · 2 wks

Dashboard

job_comms thread per job · Agent KPIs · Escalation inbox

Client Journey & Provider Flow

📘 Provider Model — Two Types, One Marketplace

⚡ Key Architecture Point for Grigori

⚠️ Grigori — Bid Presentation Note

📌 Routing Principle

⚠️ Company Dispatch SLA

✅ Trust Score in Routing

🏗️ DB Objects Involved

⚠️ Important — Commission Rules

📌 How Blue Team Differs from Green Team

✅ Client Experience — Identical

⚠️ Grigori — Company Awareness

📌 Purpose — Why This Exists

✅ Benefits to the Company

⚠️ DB Flag Required

⚠️ Plan A/B = Pricing Only — Not Provider Types

📌 Schema Source

🌍 Two Separate Money Rules — Do Not Combine Them