Where the wiki lives, how to log in, and how to add or edit pages and sections.

This wiki is the single source of truth for how we run the glass business — SOPs, best practices, and flowcharts. It lives at wiki.bcbautoglass.com and is generated from a Git repository, so every change is versioned and nothing gets lost.

How it works

• The wiki is a static site (Astro Starlight) in the bcb-wiki-new GitHub repo under the OwnerOperated organization.
• Pages are plain Markdown files under src/content/docs/.
• Pushing to main automatically rebuilds and publishes the site (Cloudflare Pages, ~60 seconds).
• Flowcharts are written as Mermaid code blocks right inside the Markdown — they render as diagrams on the page.

Editing pages (no coding required)

Option 1 — Pages CMS (quick browser edits):

1. Go to app.pagescms.org and log in with GitHub.
2. Open the bcb-wiki-new repo. You'll see every wiki page listed.
3. Edit in the visual editor and hit Save — it commits for you, and the site republishes in about a minute.

Option 2 — "Edit page" link: every page has an Edit page link in the footer that opens the file on GitHub — edit and commit right in the browser.

Option 3 — Claude assistants (the dedicated editor's workflow):

For team members editing the wiki regularly, we have a guided workflow:

• The BCB Wiki Assistant Claude Project (on claude.ai) interviews you about the change, drafts the markdown in the correct format, and produces a handoff block.
• Claude Code, running locally in your BCBWIKI/bcb-wiki/ folder with a CLAUDE.local.md safety-rail file, saves the change and pushes it.
• The safety rails restrict edits to src/content/docs/ — config, components, and site structure cannot be touched.

If you want this setup, ask your tech contact. They'll clone the repo to your machine, install Claude Code, drop the safety-rail file in place, and hand you a HANDOFF.md with the daily workflow.

Adding a page

Create a new .md file in the right section folder (via Pages CMS, GitHub, or the Claude workflow):

Every page needs this at the top (Pages CMS fills it in for you):

---
title: My page title
description: One line that shows up in search.
---

New pages appear in the sidebar automatically. To add a whole new section, create the folder and add one line to the sidebar list in astro.config.mjs — this is a developer task, not a wiki-editor task.

Adding a flowchart

Add a fenced code block with the language mermaid:

```mermaid
flowchart TD
  A[Customer submits form] --> B[Email + text goes out]
  B --> C{Booked?}
  C -- Yes --> D[Schedule the job]
  C -- No --> E[Follow up]
```

That renders as:

flowchart TD
  A[Customer submits form] --> B[Email + text goes out]
  B --> C{Booked?}
  C -- Yes --> D[Schedule the job]
  C -- No --> E[Follow up]

House rules

• No passwords or API keys on this wiki, ever. Credentials live in the server .env, encrypted in the dashboard DB, or in a gitignored CLAUDE.local.md — never here.
• Keep pages task-shaped: someone should be able to follow a page top-to-bottom and get the job done.
• If you fix a process, fix the wiki page in the same sitting.

The BCB group, XPRO Bay Area operations, the brands, and where everything lives.

We operate auto glass repair & replacement businesses across California, Arizona, and Washington, organized under two umbrellas plus a holding-company brand.

The two groups

BCB Auto Glass Group (bcbautoglass.com) is the multi-state holding-company landing page that ties the brands together. This wiki lives on a subdomain of it: wiki.bcbautoglass.com.

Operating entities (ops dashboard)

The BCB Glass Ops dashboard runs day-to-day operations for three entities:

• LA — Auto Glass of LA
• SFV — San Fernando Valley
• DelMar — Del Mar

Each entity has its own phone/text number, Google review link, and payment details (Zelle/Venmo), all configured in the dashboard under Admin → Entities.

The systems at a glance

For how they connect, see the systems map.

Who's who

• Alex — owner/operator across all businesses.
• Celia Calle — ops dashboard handoff contact (dashboard went live June 23, 2026).
• Contractor techs — do the installs; paid daily via the dashboard's End-of-Day Summary.

One flowchart that ties every system together — from ad click to money in the bank.

Everything we run, on one page. Follow the money: ads → website → lead → job → payment → reconciliation.

flowchart TD
  subgraph AC[1 · Acquisition]
    direction TB
    ADS[Google Ads<br/>3 location accounts under one MCC] --> SITES
    ORG[Organic / GBP] --> SITES
    SITES[Marketing websites<br/>9 brand sites on Cloudflare Pages]
  end

  SITES -->|Quote form submit| NOTIFY

  subgraph LD[2 · Lead delivery]
    direction TB
    NOTIFY["/api/notify Cloudflare Function"] --> EMAIL[Email to shop inbox<br/>via Resend]
    NOTIFY --> PODIUM[Podium contact + welcome text<br/>first name only]
    NOTIFY -.-> LEADDB[Lead storage<br/>webhook upsert by lead_id]
  end

  EMAIL --> OPS
  PODIUM --> OPS

  subgraph OD[3 · Operations — BCB Glass Ops dashboard]
    direction TB
    OPS[Intake: lead becomes a job] --> SCHED[Schedule + assign tech]
    SCHED --> WORK[Work complete<br/>payment preference gate]
    WORK --> PAY[Record payment]
    PAY --> DRIP[Review drip texts]
    WORK -.-> WARR[Warranty visit<br/>if issue reported]
  end

  PAY --> EOD

  subgraph MO[4 · Money]
    direction TB
    EOD[End-of-Day tech payout] --> CHASE[Chase bank + credit card]
    CHASE -->|Plaid daily pull| LEDGER[Bank ledger<br/>weekly reconciliation]
    ROAS[ROAS report<br/>ad spend vs booked revenue and profit]
  end

  PAY --> ROAS
  ADS -.->|Daily metrics pull| ROAS

The four layers

1. Acquisition — Google Ads and organic traffic land on one of the 9 marketing sites. Each site's business data (phone, hours, service areas) lives in one config file.
2. Lead delivery — a form submit instantly fires an email to the shop inbox and a Podium welcome text, and stores the lead. No Slack, anywhere. Details: lead flow.
3. Operations — the ops dashboard takes the job from intake through scheduling, completion, payment, tech payout, and review requests.
4. Money — every dollar is accounted for: Plaid pulls Chase transactions daily, the team reconciles weekly, and ROAS ties ad spend back to booked profit per location.

Exactly what happens the moment a customer submits a quote form — and the rules that must never break.

When a customer submits a quote form on any glass marketing site, this — and only this — happens:

flowchart TD
  FORM[Customer submits quote form] --> FN["/api/notify Cloudflare Function<br/>runs on the site itself"]
  FN --> EMAIL[Email to the shop inbox<br/>sent via Resend]
  FN --> PC[Podium contact created<br/>status: new lead]
  FN --> PT["Podium welcome text<br/>uses FIRST name only"]
  FORM -->|Webhook, upsert by lead_id| DB[Lead stored in the sales dashboard]
  EMAIL --> TEAM[Team follows up]
  PT --> TEAM

The rules (locked with the owner)

1. There is NO Slack anywhere in this flow. Alerts are email + Podium, period. The dashboard's Slack hook is a deliberate no-op — don't design anything around Slack.
2. Name is always ONE line ("First Last") in every payload — even when the form UI has separate First/Last fields, the payload sends a combined name.
3. The Podium welcome text uses the first name only (notify.js splits the combined name).
4. Alerts vs storage are separate jobs: alerts = the site's /api/notify Function (Resend email + Podium); storage = the dashboard webhook. Neither depends on the other.
5. Zapier is retired. The sites went through a Zapier → notify cutover; the notify.enabled flag keeps a reversible fallback path, but the target state is notify-only.

Single-step vs two-step forms

• BCB sites (SFV, Scottsdale, Bellevue, Del Mar, AGLA): single-step form with one "Full Name" field. One submit fires the whole flow above.
• XPRO sites (Walnut Creek, Gateway, A Plus): two-step form — intentionally different, do not collapse it. See two-step forms for the partial/complete logic.

Where the pieces live

Gotchas that have bitten us

• Cloudflare env vars only bind on a NEW deployment. Setting/changing a Pages env var does nothing until you redeploy (an empty commit works). If notify "silently does nothing," check this first.
• Origin allowlist lives in TWO places on the dashboard side: the config default and the prod .env override. Editing only the config is a silent no-op if the env var is set.
• Stale Podium tokens per CF project: each Pages project carries its own Podium token. A token minted before a scope fix will 403 on contact creation while the welcome text still sends. Fix: copy the current refresh token + client credentials from a working project, remove any static access-token override, redeploy.

How the partial/complete two-step quote form works, and the SOP for rolling it out to a site.

The XPRO sites use a two-step quote form — step 1 captures contact info, step 2 captures vehicle/insurance details. It's intentionally different from BCB's single-step form; don't collapse it.

flowchart TD
  S1[Step 1: name, phone, email] -->|submit| P1["Fires PARTIAL<br/>(client-generated lead_id)"]
  P1 --> E1[Email #1 to shop inbox]
  P1 --> POD[Podium contact + welcome text]
  P1 --> UP1[Dashboard lead CREATED<br/>keyed on lead_id]
  S1 --> S2[Step 2: vehicle, VIN, insurance, comments]
  S2 -->|submit| P2[Fires COMPLETE<br/>same lead_id]
  P2 --> E2[Email #2 with vehicle + insurance details]
  P2 --> UP2[Dashboard lead UPDATED<br/>same lead — no duplicate]
  P2 -.->|"No second Podium text"| POD

The logic

• Step 1 (partial) fires immediately — the lead is real as soon as we have a name and phone. Email + Podium contact + welcome text + dashboard lead, all at once.
• Step 2 (complete) sends a second email only (vehicle/insurance details) and updates the same dashboard lead by lead_id. No second Podium text — the customer already got one.
• A complete arriving with no prior partial creates a full lead. Posts are fire-and-forget, so order isn't guaranteed — the dashboard merges payloads only on complete so a late partial can't regress the data.
• The dashboard never updates a lead a rep has already claimed/closed, or anything older than a day — lead_id is client-generated and replayable, so the public endpoint must not mutate worked leads.

Form fields (preserve all of them)

• Step 1: first, last, phone (intl-tel-input, E.164), email + honeypot field.
• Step 2: city/ZIP, repair type, year, make, model, VIN/plate, uses-insurance, insurance company, comments.
• Payloads carry lead_id, submission_status (partial/complete), form_name, and page metadata — plus the combined one-line name.

The dashboard captures the extras (VIN, insurance company, uses-insurance) and shows a Partial / Complete "Form" badge on the lead.

Rollout SOP (per site)

Walnut Creek shipped first (end-to-end verified 2026-07-07). Gateway and A Plus are near-verbatim copies. For each site:

1. Dashboard first: confirm the site's domains (apex + www + its staging host) are in the web-lead origin allowlist — both the config default and the prod .env override.
2. Port QuoteForm.astro + step-aware functions/api/notify.js + the salesDashboard / notify blocks in site.ts from the Walnut Creek repo. Delete the old quote-form.js / form-handler.js.
3. Set Resend + Podium env vars on the site's Cloudflare Pages project, then redeploy (env vars only bind on a new deployment).
4. On the staging preview: submit step 1 → confirm email + Podium text + dashboard lead. Submit step 2 → confirm second email + the same lead enriched (not a duplicate).
5. Owner approves → merge staging → main (production cutover; Zapier stops receiving).
6. Cleanup: delete test leads from the dashboard; after the full fleet is rolled out, remove the *.pages.dev / staging hosts from the origin allowlist.

All 9 marketing sites plus the holding-co page — repos, domains, and which flavor each one is.

One repo per location, all under the OwnerOperated GitHub account, all deployed on Cloudflare Pages.

The three flavors

Standard Astro (most sites) — Astro + Tailwind v4, static output. All business data is in one file: src/config/site.ts — phone, address, hours, service areas, brand colors, webhooks, TrustIndex review-widget IDs, Google Maps embed. Edit there, never hardcode. Homepage sections live in src/components/sections/*.astro, legal pages in src/components/pages/ + src/pages/, site chrome in src/layouts/BaseLayout.astro, assets in public/.

Custom Astro (two exceptions):

• bsag-astro — rebuild of an old Next.js export. No site.ts: copy, phone, prices, webhook, GTM and TrustIndex IDs live directly in the .astro files (src/pages/index.astro, src/layouts/Base.astro, src/components/QuoteForm.astro). Only the homepage and /warranty exist; old subpages 301 to /.
• agla-website-astro — uses site.ts for core business data, but most pages are pre-generated HTML snapshots whose inner blob keeps a baked-in copy of the data. When changing business info, check both places.

Static HTML — bcbautoglass is a single index.html, no build step. Edit the HTML directly.

Where things run

• Cloudflare Pages auto-builds on every push (npm run build, output dist/, Node 20).
• Push to staging → preview URL (*.pages.dev). Push to main → production.
• See deploying a site change before touching main.

How to change phone numbers, hours, prices, copy, or images on any of the marketing sites.

Changing business info (phone, hours, address, service areas)

On a standard site, one file holds everything: src/config/site.ts.

1. Open the site's repo, switch to the staging branch.
2. Edit the value in src/config/site.ts — phone, address, hours, service areas, brand colors, webhook URLs, TrustIndex IDs, Maps embed all live there.
3. Never hardcode a phone number or address in a component — if you find one hardcoded, that's a bug; move it to site.ts.
4. Push staging, check the preview URL, then follow the deploy SOP to promote to main.

The exceptions

• bsag-astro — there is no site.ts. Edit the .astro files directly (src/pages/index.astro, src/layouts/Base.astro, src/components/QuoteForm.astro).
• agla-website-astro — edit site.ts and check the pre-generated HTML snapshot pages, which keep a baked-in copy of business data in their inner blob.
• bcbautoglass — plain index.html, edit directly.

Changing page copy or sections

• Homepage sections: src/components/sections/*.astro — one file per section.
• Legal pages: src/components/pages/ + src/pages/.
• Header/footer/site-wide chrome: src/layouts/BaseLayout.astro.

Images & assets

Put files in public/ and reference them by absolute path (/images/...). Compress before committing — these are marketing sites; page speed matters for Ads quality score.

Quote form / lead delivery changes

Anything touching the quote form or notify Function must preserve the canonical lead flow — one-line name, first-name-only Podium text, no Slack. Test on the staging preview with a real submission before promoting, then delete your test lead from the dashboard.

Golden rules

• Local first — never edit anything on production servers directly.
• Work on staging, verify the preview, promote to main. Those are the only two branches — never create others.
• Never build or commit dist/ or node_modules/ — Cloudflare builds from source.

The staging → preview → approval → production flow for the marketing sites.

Every marketing site deploys the same way. Pushing to main is a live production deploy — treat it accordingly.

flowchart TD
  A[Make the change on the staging branch] --> B[Push staging]
  B --> C[Cloudflare Pages builds a preview<br/>site-name.pages.dev]
  C --> D{Preview looks right?<br/>Forms tested if touched?}
  D -- No --> A
  D -- Yes --> E{Customer-facing change?}
  E -- Yes --> F[Get explicit owner approval]
  E -- "Internal/trivial" --> G
  F --> G[Merge staging into main and push]
  G --> H[Cloudflare builds and deploys PRODUCTION]
  H --> I[Spot-check the live site]

The rules

1. Two branches only: main + staging. Never create feature/fix/throwaway branches — they drift and cause mistakes. Delete strays on sight. main is the source of truth; staging is always a clean copy of it plus the change being verified.
2. Verify on the preview first (*.pages.dev), or locally with npm run build && npm run preview. Never push to main unverified.
3. Production pushes are approval-gated. "Push" or "deploy to staging" never implies production. When in doubt, ask.
4. Cloudflare runs npm run build (output dist/, NODE_VERSION=20). Never commit dist/ or node_modules/.
5. Env-var changes need a redeploy. Cloudflare Pages Functions only bind new env vars on a fresh deployment — push an empty commit if there's nothing else to ship.

Verb glossary (so nobody miscommunicates)

After deploying

• Spot-check the live page you changed.
• If the quote form was touched: submit a test lead end-to-end (email + Podium text + dashboard lead), then delete the test lead from the dashboard.

BCB Glass Ops — what it does, who can do what, and the ground rules.

BCB Glass Ops is the internal dashboard that runs day-to-day operations for the three BCB entities — LA (Auto Glass of LA), SFV (San Fernando Valley), and DelMar (Del Mar). It went live on Cloudways on June 23, 2026.

The job it does: intake WhatsApp/SMS leads → schedule → assign a contractor tech → collect payment → pay the tech → send transactional + review texts.

Roles — who can do what

Only a super_admin can grant elevated roles. Accounts are managed under Admin → Employees.

The main areas

Ground rules

• Times: everything is stored in UTC and displayed/scheduled in Pacific time. If reminders ever go out an hour off, the timezone config broke — flag it to Alex/Claude.
• Entity data matters: review-request texts refuse to send until the entity's Google review URL is set, and Zelle/Venmo payment texts refuse until the entity's payment details are set (Admin → Entities). If a text "won't send," check there first.
• Credentials (SMS providers, Google Ads, Plaid) are stored encrypted in the database and edited only via Admin → Integrations & API Keys — never in code, never on this wiki.
• Stack, for the technically curious: Laravel 12 + Filament 4, MySQL, hosted on Cloudways. Deploys are covered in deploying the dashboard.

How Xpro CSR, the BCB scheduling team, suppliers, and field technicians work together — from lead intake through payment, across the whole BCB group.

This is the group-wide scheduling SOP — it runs through Xpro CSR and Omega EDI on top of, not instead of, the normal BCB Glass Ops dashboard flow, for every BCB entity (LA, SFV, DelMar, and beyond). Lead intake happens in Omega first; scheduling still finishes in the dashboard (Step 1 below). Some details below (supplier accounts, technicians) are shown for the LA market as the reference example — other markets follow the same process with their own local suppliers and techs (see the Technician Directory for San Diego's supplier list).

1. Purpose

Keep a consistent, efficient workflow between Xpro CSR, the BCB scheduling team, suppliers, and field technicians — from lead intake to technician scheduling and CRM updates.

2. Roles

Xpro CSR

• Handles lead intake.
• Collects vehicle + customer info.
• Uploads all lead data to Omega EDI (CRM).
• Alerts the BCB scheduling team when a new lead is ready.

BCB scheduling team

• Reviews new lead details in Omega EDI and the Google Sheet Jobs Tracker.
• Confirms part availability and pricing with suppliers.
• Communicates job details to the technician.
• Confirms the arrival window with the customer.
• Updates the job tracker.

3. Systems & tools

• Omega EDI (CRM) — lead & job details.
• BCB Dashboard — where scheduling is finalized (see job lifecycle).
• Google Sheets — Jobs Tracker — columns L–P must be updated after booking. Can also be used as a backup to check info from the sales team before asking them directly.
• Quo — communication with technicians.
• Podium (Xpro login).
• Recal Tracker — the ADAS calibration reference spreadsheet — used to check whether a recal has been scheduled and where it stands.
• Stripe — processing debit/credit card payments.

Supplier accounts (IGC, Mygrant, Pilkington, PGW, O'Reilly, Lexus of Glendale, Kearny Mesa Hyundai, Audi Pasadena — the LA market's suppliers) are listed in parts ordering & suppliers below. Per Secrets & access, no login password ever goes on this wiki — portal logins live with the team's password manager; ask Alex/Celia for access.

Workflow steps

Step 1 — Lead intake by Xpro CSR

1. Xpro CSR gathers:
   • Year / Make / Model
   • Repair type (front windshield, back glass, side glass)
   • VIN or part # if available
   • Customer name & phone number
   • Address + ZIP code
   • Any special notes (e.g. "call 20 min before")
2. CSR uploads this info into Omega EDI.
3. CSR notifies the BCB scheduling team via WhatsApp that a new lead is ready.
4. Scheduling team confirms all details are in the message: car make/model/year, part number, quote value, requested date/time if any, full name, phone number, address, entity name.
5. Proceeds to do lead intake in the dashboard.
6. Xpro Team sends the lead's name to the group and asks if it's possible to take on — always respond YES immediately. We have 10+ techs in LA who could do it; we'll make it work.

Insurance jobs

For every insurance-approved job, there are always two separate appointments:

1. Auto glass replacement
2. ADAS calibration (handled separately)

The technician completes only the glass replacement on the first visit. Calibration is scheduled and handled by our team as a second appointment — if the client asks about calibration, they should be referred back to us. Explain up front that the job happens in two phases (glass, then calibration); see also ADAS calibration jobs.

• Once the glass job is completed, tag @Tulio in the WhatsApp group and request coordination of the recalibration. Track progress in the Recal Tracker; if there's no progress in 48h, follow up.
• Try to collect payment after the glass job is completed and before the recal. If the client asks to wait until the recal to pay, that's fine.
• If the job requires both recalibration and glass replacement, coordinate the glass replacement first, then hand off to David's team to coordinate the calibration as the second appointment.

Step 2 — Confirm technician's availability

Call the technician to confirm:

• Whether they can take the job.
• That the part number Xpro provided actually fits the car/issue they see in the lead's photos.
• When they can pick up the part.
• What day/time they can be at the job site — aim for same-day.

Step 3 — Check part availability & order parts

1. Identify the nearest warehouses based on the job location and the technician's other jobs that day, so the pickup lines up with their route.
2. Call or check supplier portals to confirm availability, price, and place the pickup order (will-call).
3. Choose the supplier based on lowest cost, availability, and proximity to the job site or the tech's route.

Timing rule: place the part order within 24h of the job. Example: job scheduled Monday for Friday → call Thursday to order. If a weekend or holiday falls in between, place the order and then call again Monday morning to verify it's still on will-call (ready for pickup).

Supplier contacts:

For every order: note the pickup location for the technician.

Finding the part number: check Omega under Items for that lead, or the job tracker's column K — "part#". Omega may also show SRI (labor) and HAH (the adhesive used) — neither of those needs to be ordered.

Technician notification & routing policy

As volume grows and more LA technicians come on board, routes need careful management to avoid confusion, inefficiency, or conflicts between techs.

1. Technicians are only informed of a job once the daily route is finalized. We don't send jobs ahead of time — this stops techs from assuming a job is already theirs before scheduling is locked in.
2. Route assignments are optimized first, then communicated. The scheduler designs the most efficient route by location, timing, and part availability; only then do jobs go out to technicians.
   • If a technician is running late and won't make their next appointment on time, always try to find an alternative tech with availability to honor the original scheduled time. Only if that's impossible, ask the client to reschedule.
3. The goal: stay flexible, avoid upsetting techs with schedule changes, reduce the risk of overpromising/underdelivering, and keep routes efficient and balanced across all technicians.

After-hours / incomplete job follow-up

• Installation still in progress or not fully complete at end of shift: leave a follow-up assigned to the shared pool (see Follow Ups) to take care of it. If payment still needs to be collected, send Celia a WhatsApp before the end of your shift so she can monitor it. List the pending actions clearly — payment collection, review request, any remaining work.
• Job completed after hours: leave a follow-up. The first team member in after 8:00 AM is responsible for reaching out to the customer, collecting payment, and closing out any remaining follow-up steps.

Step 6 — Update Job Tracker and Omega

Update columns L–P after the job is scheduled — typically:

• Arrival window confirmed
• Technician assigned
• Supplier & warehouse pickup location
• Notes (tech notes, part notes, delays, customer comments, etc.)

Keep this consistent with what was actually shared with the technician and the customer. Also update the appointment date/time with the customer in Omega EDI.

If the customer reschedules or cancels: let the technician know as soon as possible. If rescheduled, confirm the next available time. Update the CRM + job tracker immediately.

Step 7 — Ask for payment

1. Debit/credit card: process a link through Stripe.
   • Debit: no processing fee added (it's only 1%).
   • Credit: add 3% extra to the amount for processing fees.
   • Include a picture of the repaired zone when possible, plus the vehicle detail (year, brand & model, glass repaired).
2. Cash: let the technician know exactly how much the client owes, then follow up with the technician until they Zelle us the full amount.

Venmo: not a standard payment option — only offer it if the client explicitly asks. In that case they can send payment directly to the owner's Venmo (@alex-borkin); mention it only when requested or truly necessary.

9. Escalation procedures

Escalate to Celia when:

• Part unavailable at the main warehouses → try alternate IGC locations across LA.
• Technician fully booked → check Jason's availability, or reschedule.
• Urgent issue → call.
• Client request (not urgent) → tell the client it's been escalated and we'll follow up within 24h; create a ClickUp card for Celia to manage.

11. Upload job-finished photos

Upload every job-finished photo the tech sends into the shared job photos Drive folder.

12. Cancelled jobs

When a job is completely lost or cancelled after the part has already been ordered:

1. Instruct the technician to return the part to the warehouse they picked it up from, and share our business account info for that specific warehouse.
2. Verify with the technician that the return is in progress.
3. Follow up with the warehouse to confirm the return was received and that our account wasn't charged.

13. Part price difference threshold

Generally use the warehouse the technician recommends — it's usually the most efficient choice and avoids extra travel charges.

Before placing the order:

• Compare the technician's selected warehouse price against the price the sales team (David's team) provided.
• A difference of up to $20 is acceptable — no additional approval needed.
• If the technician's preferred part is more than $20 higher than the sales-team price, do not order immediately — escalate the discrepancy to Alex/Celia for review and approval first.
• Factor in whether switching warehouses would add technician travel charges that offset any savings on the part itself.

Goal: minimize the total job cost (part + technician travel/time), not just the part price.

Client non-payment SOP

Goal: attempt collection consistently, document every attempt, and escalate to Celia before it becomes a bigger issue.

The key rule: don't keep contacting the client indefinitely without telling Celia. After 3 unsuccessful payment attempts with no payment or meaningful response, notify Celia. An "attempt" means an actual contact — call, text, or email — and every attempt must be logged.

What to report when escalating:

• Client name
• Invoice/job number
• Amount owed
• Original due date
• Number of attempts, with dates/times and method (call/text/email)
• Whether the client responded, and what they said
• Any promised payment date
• Screenshot/documentation if relevant

Automatic escalation after 3 failed attempts applies to: no response, unanswered calls, ignored messages, or a client who keeps saying they'll pay but doesn't.

Other cases:

• Client disputes the invoice — refer back to the quote sent before the appointment (sent a couple of times); they agreed to move forward on that quote.
• Client claims the work was defective — mark the job "Warranty / need fixing," collect photos and details, and send them to the technician to schedule a warranty visit (see Warranty jobs). Let the client know we're working on it and keep them updated.
• Client refuses to pay — get the details; if it's not a warranty claim, escalate to Celia immediately.
• Client says they already paid — check the bank account and/or Stripe to verify. If there's no reference, ask for payment proof and wait 24h to see if it clears. If it still doesn't show after 24h, ask them to check with their bank and try again.
• Client requests a discount/credit to resolve the balance — deny in most cases; if they push, the fallback is waiving the credit-card processing fee, not the balance itself.

Immediate escalation (no waiting for the 3-attempt threshold):

• Client threatens a chargeback/dispute or any legal/collections threat — if they aren't visibly angry, tell them it's been escalated to a manager and we'll respond within 24h, then create a card for Celia to review. If they're threatening to act immediately, call Celia right away.

Suggested internal workflow:

Due → Attempt 1 → Attempt 2 → Attempt 3 → CELIA

After each attempt: Update CRM → set next follow-up → continue. Once it reaches Celia: Celia decides — continue collection / adjust the invoice / dispute resolution / collections / write-off / other action.

Annex — handling insurance virtual card payments (Auto Glass of LA)

Trigger: Alex sends a virtual card (via WhatsApp group or ClickUp). Priority: time-sensitive — process immediately upon receipt. Full walkthrough: Loom video.

Step 1 — Verify the payment amount

• Compare the card amount vs. the expected job payout in Omega.
• Expected = total job amount − deductible.
• Within expected range → proceed.
• Less than 25% of expected amount → flag in the team chat, and contact the insurance company to request a correction/reissue before processing.

Step 2 — Process payment in Stripe (AGLA)

1. Log into the AGLA Stripe account.
2. Go to Billing → Invoicing → Create new Invoice (the + icon, top right → Invoice).
3. Customer name: the insurance carrier (e.g. Mercury Casualty Company).
4. Line item: description "Auto glass repair – Claim [claim #]," amount = the exact amount listed (no partials unless approved), quantity 1.
5. Select Auto Charge Customer and enter the virtual card's number, expiration, and CVV.
6. Submit payment (finalize the invoice).

Step 3 — Confirm fees

Make sure no unexpected Stripe fees were deducted. If fees were taken, screenshot the transaction and flag it internally — these should typically be avoided or accounted for.

Step 4 — Record & close

Mark the job Paid in Omega/CRM, attach the Stripe payment screenshot as proof, and send it to the group chat with Alex.

How to make an invoice/receipt: Loom walkthrough.

Technician documentation & 1099 requirements

See the full W-9/1099 tracking table on the Technician Directory. The group-wide rule: a new technician can be used for their first jobs while documentation is pending, but after 3 completed jobs we must have their W-9/1099 info before assigning more work. If a technician keeps refusing to provide it, remove them from the active technician roster.

A job from intake to completed — scheduling, payment gate, cash handling, reviews, and the warranty branch.

flowchart TD
  LEAD[Lead arrives<br/>web form / WhatsApp / SMS] --> INTAKE[Intake: create job<br/>quote, vehicle, insurance flag]
  INTAKE --> SCHED["Schedule + assign tech<br/>(a tech MUST be assigned first)"]
  SCHED --> REM[Automated reminder texts]
  REM --> WC{Mark work complete}
  WC -->|Unpaid job| GATE[Payment preference gate<br/>required choice]
  GATE -->|Zelle / Venmo| TXT1[Text with payment details<br/>from the entity settings]
  GATE -->|Credit card| TXT2[Stripe payment link texted]
  GATE -->|Cash| CASH[No text — tech collects]
  TXT1 --> PAY[Record payment]
  TXT2 --> PAY
  CASH --> PAY
  PAY --> WELL{"How did the job go?<br/>(required on record payment)"}
  WELL -->|Thumbs up| DRIP[Review drip starts]
  WELL -->|Thumbs down| SKIP[No review texts]
  PAY --> DONE[Job completed]
  DONE -.->|Customer reports an issue| WARR[Warranty claim]
  WARR --> WVISIT[Schedule return visit<br/>unpaid, defaults to original tech]
  WVISIT --> WRES[Mark resolved]

Key rules

• A technician must be assigned before a job can be scheduled, completed, or have a payment recorded.
• Marking work complete on an unpaid job forces a payment-preference choice — Zelle, Venmo, credit card, or cash. The matching text fires automatically (Zelle/Venmo texts pull the entity's payment details; credit card creates/re-sends a Stripe link; cash sends nothing). Completion itself is never blocked by a text failing.
• Recording a cash payment immediately adds that cash to the tech's balance (they're holding our money). See tech pay.
• "How did the job go?" on the record-payment dialog is required: 👍 starts the review drip; 👎 skips it quietly.
• Receipts are on-request only — a paid job's actions menu has Send receipt; nothing goes out automatically.
• Customer names auto-normalize ("JOHN SMITH" → "John Smith") everywhere, including texts — no need to fix capitalization by hand.

Jobs board tabs

The Operations → Jobs board organizes every job into tabs: Needs scheduling, On hold, Scheduled, Work done, Paid, All jobs, plus an Insurance tab (see Insurance jobs below). A new lead lands in Needs scheduling with status pending schedule and sits there until booked. A job whose requested day is today or already past is flagged urgent on that tab, and also posts in the 7am Telegram digest.

Scheduling a job

1. Open the job from Needs scheduling and click Schedule (from the actions menu, or as a row action on the board).
2. Set the date, time window, and technician — a technician must be picked before the job can be scheduled at all. Their base pay is applied automatically once picked, fixed to their rate on file — it's never typed in by hand.
3. Pick the warehouse — required unless the job is Labor only (the customer already owns the glass). Choose one of the shop's own warehouses, or "Other" and type the supplier's name.
4. Resolve any warning the form shows — see Checks at the schedule step.
5. Submit. The job moves to Scheduled, the customer gets a time-confirmation text, and the technician gets one text with every job detail — address, time, vehicle, part number, and warehouse.

For jobs where the technician still needs to agree on a time, use Schedule w/ AI instead of the manual form — it texts your ranked list of techs in order and books the first accepted slot, following the same warehouse, deadline, and part checks as manual scheduling.

Checks at the schedule step

The schedule form can stop you, or ask you to confirm past a warning, in four cases — none appear unless the job actually triggers them:

• Before-a-time deadline — the customer asked for the job done by a named hour. Booking a slot that finishes too late shows a warning with the latest safe arrival time. You can still book it, but must tick an override box and give a reason — that override is logged.
• Part number vs. glass position mismatch — the part number on file names a different piece of glass than the "Glass position" field says (e.g. a windshield part on a job marked "door"). This blocks scheduling until you fix one of the two fields, or tick an override box with a required reason. Either way it's logged.
• OEM parts deposit — triggers only when the chosen warehouse is a dealer or an unlisted "Other" supplier, since OEM parts are non-refundable once ordered (see Deposits below for the amounts). Short on deposit needs an override checkbox and a reason.
• Distance pay — this is the only place distance pay can be granted. A toggle asks whether this is expected to be a distance-pay job, and takes an amount capped at $50. If the technician already has another job that same day, the form challenges you to confirm it's really needed before you can grant it.

After a job is booked

• Order the part — go to Operations → Parts to Order, or use Order part on the job. Enter the part's real cost — optional at intake, but required here. If the warehouse is "Other," also mark it prepaid once you've paid the supplier; an unpaid "Other" part sits on hold.
• Reschedule or cancel, if plans change — Reschedule keeps the job booked and re-checks every warning above against the new date/time. Cancel appointment returns the job to Needs scheduling, texts the customer, and asks whether a part needs to be returned.
• Mark work complete — see Key rules above for the payment-preference gate. Payment options are Zelle, Credit card, Venmo, Cash, or Check; an already-paid job just sends a plain wrap-up text instead.
• Record the payment — each payment recorded adds its own line, so a deposit plus a later balance both show (see Deposits). Cash goes onto the technician's running balance right away.
• The review request opens on its own the moment work is marked complete — see the review drip.

Scheduling hold

Use a hold when a lead can't be booked today because you're waiting on the customer — they need to check a schedule, approve a quote, or hear back from their insurer. A held job leaves the Needs scheduling tab but stays in the pipeline; nothing about the job is canceled by a hold alone.

Put a job on hold (works whether it's unbooked or already Scheduled):

1. Open the job's actions menu → Put on scheduling hold. If the job was already Scheduled, this cancels that appointment first — same as a manual cancel, including the customer text and the parts-pickup question — then places the hold.
2. Type a reason — required. The form suggests common ones, but free text works too. A hold with no reason isn't allowed.

Take a job off hold:

1. Open the job on the On hold tab, or from the job's own page — it shows an "On hold" badge with the reason and how many days it's been sitting.
2. Take off hold — optionally note what the customer said (not required).
3. Schedule the job — it returns to Needs scheduling right away. Booking it directly also clears the hold on its own.

A held job posts in every daily Telegram digest under "On hold" until it's released, booked, or marked lost — so it's never silently forgotten. Re-holding an already-held job just updates the reason and restarts the day count.

Insurance jobs

• Flag is_insurance at intake (or later in the job's Money section). On an insurance job the quote = the customer's deductible — recorded through the normal payment flow.
• The insurer's payment is a separate fact, recorded via Record insurance payment in the job's actions menu. It does not gate job completion.
• The jobs board has an Insurance tab; its badge counts jobs still awaiting the carrier.
• Note: ROAS revenue counts only the deductible on insurance jobs (by design, for now).

Deposits

Collect a deposit before the job is worked (before ordering/paying for a part, or before dispatching for labor/inspection-only work) in these cases:

Tracking deposits in the dashboard: mark each deposit as its own payment on the job's Money section — a job that collects a deposit and then a final payment will show two payments on the job page. Record each one at the time it's actually collected; don't wait and log them together after the fact.

Stripe payments no longer need to be marked paid by hand. The dashboard auto-records a Stripe payment as soon as Stripe receives it. This automatic tracking only applies to Stripe — Zelle, Venmo, and cash payments (deposits included) still need to be recorded manually, the same as before.

Adjusting confirmed amounts

Tech payments and part payments are usually entered as an estimate first (a quoted part price, a planned labor amount). Once the real number is confirmed — the part's actual price at the moment we pay for it, or the actual amount paid to a tech — always go back and adjust the recorded amount on the job to match. Profit, ROAS, and tech payouts are all calculated from these numbers, so a stale estimate throws all of it off.

Parts — price verification

Always verify the part's real price at the moment we pay for it, not before:

1. If the confirmed price is more than $20 higher than the quoted part cost, check an alternative provider before paying.
2. If every provider is running higher, calculate the job's profit: total quote − labor cost − part cost.
3. If that profit comes out to roughly $150–$200 or lower, flag the job to David's team and consider requoting the client.

For LA Auto Glass specifically, see the fuller supplier/warehouse-selection process in the BCB scheduling SOP.

Warranty jobs

Post-completion "customer reports an issue" flow, under Operations → Warranty. Use this when a customer reports a problem after the work is done — the glass leaks, whistles, or something feels wrong. The return visit is unpaid to the customer, and unless extra pay is added, unpaid to the tech too — it never touches the original job's money.

• The job must already be work-completed or completed. As soon as a claim is reported, open the job's actions menu → Warranty / fix needed, and write down what the customer reported — before any further investigation. This is what flags the claim in the dashboard and lets the team track and follow up on it correctly; do not wait until the issue is diagnosed to log it.
• The new claim then appears on Operations → Warranty as open, waiting to be booked.
• Schedule visit — same date/time/window/technician fields as a normal job; it defaults to the original tech. One automatic, deliberately generic text goes to the customer once it's booked — the word "warranty" never reaches the customer. If the tech needs extra pay for the visit, toggle it on and set an amount here.
• Mark complete requires a 👍/👎 on how the visit went — this is informational only, it does not start a new review request.
• Notes and Cancel are also available on the Warranty page, for editing the issue or dropping a claim entirely.
• Warranty visits show on the Operations calendar in purple.
• Warranty claims should be evaluated based on whether the reported issue is related to the installation or represents new damage occurring after the job. If the customer reports surface damage such as scratches after installation, document the customer's photos and the original post-installation photos before determining whether a warranty visit is appropriate.
• Do not automatically assume the glass or installation is defective based only on a customer's description or photo. If the reported issue is unclear, have a technician inspect it when appropriate.
• If a warranty cannot be extended because the new damage is outside the original warranty coverage, the limitation should be explained to the customer before scheduling any warranty work.

Standard operating procedure

Once a claim is logged, the goal is to resolve it at the ops level whenever possible, without looping in leadership:

1. Photos are the default evidence for every job. Techs send photos of the completed work, and customers are asked to send photos when they report an issue.
2. Compare the two sets of photos with the assigned tech to determine whether the issue originated with the installation or occurred afterward.
3. If the issue is on our end, the tech returns to resolve it under warranty, at the tech's own cost — this is the standing agreement with our technicians and does not require sign-off from David's team.
4. Nico and Laura are empowered to make this call themselves — open the claim, review the photos with the tech, and dispatch the return visit without waiting for approval.

When to escalate: loop in the team only when a claim involves an added cost (materials, parts, a discount, or anything beyond the tech's standard warranty coverage) or looks like more than a simple send-the-technician-back-to-fix-it visit. Route those to Celia rather than defaulting to David's team.

Chip repairs

Chip repairs should have the same $150+ profit goal with clear warranty information.

If the job does not meet that goal, aim to upsell a full windshield replacement, or choose not to take the job if it creates too much operational headache for the margin.

Job acceptance

Do NOT book unclear or exploratory jobs.

If the customer cannot clearly explain what needs to be repaired, replaced, installed, or performed, CANCEL / DECLINE.

Examples of exploratory requests:

• "Come take a look and see what you can do."
• "I'm not sure what's wrong."
• "Maybe you can fix it."
• "I just want someone to look at it."

Defined labor-only jobs ARE accepted.

Examples:

• Customer already has the window regulator and needs installation.
• Customer already has the windshield and needs installation.
• Customer has the part and clearly knows what needs to be installed.

All labor-only jobs require a $150 deposit, regardless of:

• vehicle age
• job size
• part cost
• how simple the job appears

Key rule:

• Defined labor-only job → BOOK + $150 deposit
• Undefined / exploratory job → CANCEL / DECLINE

Recalibration requests after glass replacement

This applies when a customer requests recalibration after the glass has already been replaced and recalibration was not included in the original quote.

If the customer asks via text:

• Always connect them with David's team for review.
• Do not automatically promise or approve recalibration.

If the customer asks during a phone call:

Ask whether any sensors or warning lights are currently showing.

If NO:

• Explain that installations are calibration guaranteed.
• Technicians verify cameras/sensors are working correctly after installation.
• If a sensor turns on in the following weeks/months, recalibration is provided free of charge.
• Sensors remain covered by the lifetime warranty.

If YES:

• Request a photo of the warning/sensor message.
• Contact the installation technician and ask whether it could be related to the installation.

If recalibration appears necessary:

• Consult David's team BEFORE agreeing to or scheduling recalibration.
• Confirm whether the customer had a discounted / No-Calibration quote.
• No-Calibration quotes are only used when explicitly communicated upfront as a lower-price option.
• These quotes include no calibration and no sensor warranty.

If recalibration is approved:

• Step 1: Glass installation by the installation technician.
• Step 2: Calibration, if needed, scheduled 24–48 hours after installation and handled by a software engineer specializing in camera alignment.

ADAS calibration jobs

ADAS calibration is handled separately from glass replacement.

Insurance jobs requiring calibration:

• First appointment: glass replacement only.
• Second appointment: ADAS calibration.

Customers should be informed that the job happens in two phases.

Jobs requiring both recalibration and glass replacement:

• Coordinate the glass replacement first.
• After the glass replacement is completed, coordinate the calibration appointment.

The ADAS calibration reference spreadsheet is the source of truth for calibration details.

Status quick reference

The shared dispatch to-do list — tracking promises that must not get lost between shifts.

The Follow Ups module is a shared to-do list for the dispatch team. It stores promises that must not get lost between shifts.

Examples: "Call the customer about a late part." · "Ask the tech to send cash today."

Where it lives

• Operations → Follow Ups (FollowUpResource) — lists every follow-up item.
• Job view — each job page has its own Follow Ups section, showing items linked to that job.
• Daily digests — all three daily ops messages show open follow-ups.

The data

Each item is one row in the follow_ups table.

• job_id can be empty. Many follow-ups are about a tech, a vendor, or a supplier — they aren't linked to any job at all.
• due_date is a plain text date (YYYY-MM-DD) — there's no special date type behind it.
• "Overdue" means the due date is before today, where today is Pacific time, not UTC.
• A follow-up with no due date is a normal state, not a data gap. The system sorts these last, never marks them overdue, and never includes them in the daily Telegram message.

Assignment

• An assignee is optional. With no one assigned, the item belongs to the shared team — not to any one person.
• Only dispatch staff can be assigned — technicians are excluded from the assignee list.
• Any dispatch staff can close an item, even one assigned to someone else. Assignment is about ownership, not a lock.

Closing an item

• markDone(?note, Employee) — closes the item with a result. The note is optional; most items need none.
• cancel() — cancels the item instead of completing it.
• Both actions are safe to repeat. A double-click doesn't overwrite anything — the system keeps the first result.

Daily SOP

Follow Ups is a living list, not a set-and-forget one. Dispatch should:

1. Check it at the start of shift — pick up anything left open from the previous shift.
2. Add new items as promises come up through the day (a callback owed, something to ask a tech, a vendor to chase).
3. Review it again at least a couple more times during the day — don't wait for the end of shift to find out something slipped.

The daily End-of-Day payout, rolling cash balances, and tech-fronted parts.

Two paired tools under Admin: End-of-Day Summary (pay techs daily) and Tech Balances (rolling cash each tech owes us).

A technician's base pay is applied automatically the moment they're picked at scheduling — it's fixed to their rate on file, never typed in by hand. Distance pay is the one exception: it's granted separately, only at the schedule step, capped at $50 — see checks at the schedule step.

The model in one picture

flowchart TD
  CASHPAY[Tech collects CASH on a job] -->|Immediately at recording| BAL[Tech's cash balance goes UP<br/>they owe us that cash]
  JOBS[Tech completes jobs today] --> OWED[Labor owed for the day<br/>plus any tech-fronted parts]
  OWED --> EOD{End-of-Day: Mark paid}
  BAL --> EOD
  EOD -->|"payout = max(0, owed − balance)"| PAYOUT[We pay the tech the difference]
  EOD -->|"balance = max(0, balance − owed)"| NEWBAL[Balance pays itself down]
  HANDBACK[Tech hands cash back] --> CLEAR["Clear balance (Tech Balances page)"]

Example: tech's balance is $100 (cash they collected), today's labor is $120 → we pay $20 and the balance clears to $0.

Daily SOP — End-of-Day Summary

1. Open Admin → End-of-Day Summary (defaults to today; you can step back days).
2. One row per tech who completed a job that day — jobs count, pay owed, their cash balance, to pay, and a Paid/To-pay badge.
3. Click a row (View jobs) to see the per-job breakdown — a Work line plus a Parts (tech paid) line when the tech fronted parts. It reconciles to the Pay-owed column.
4. Hit Mark paid per tech. That settles the day: pays labor net of their cash balance, stamps the jobs tech-paid, and writes an audit row.

Notes:

• We pay techs for jobs they complete — customer payment does NOT gate the payout.
• Settled techs stay visible (marked Paid), so stepping back a day or two is safe.
• There is no per-job "mark tech paid" — payouts only happen through End-of-Day.

Cash balances — Tech Balances page

• Cash a tech collects rides onto their balance the moment the payment is recorded — not at settle time. Editing a payment amount or switching to/from cash adjusts the balance (never double-counts, never goes below $0).
• Tech Balances shows every tech with a balance > 0. When a tech physically hands cash back, use Clear balance there.
• Every movement (cash collected, EOD payout, balance clear) writes an audit row, so any balance can be explained job-by-job.
• We never refund customers out of a tech's pocket — refunds go out by Zelle from us.

Tech-fronted parts

Normally we buy parts. When a tech pays out of pocket:

1. On the job's Money section, tick the "Tech paid" checkbox next to that part in the parts list — no re-typing amounts.
2. The part cost is reimbursed on top of labor at End-of-Day and shows as its own Parts line in the breakdown.
3. Margin/ROAS never double-count it — the part cost was already a job cost; it's just flowing through the tech.

Central reference for field technician contacts, capabilities, pricing, service areas, and dispatch preferences.

Central reference for field technician contacts, capabilities, pricing, service areas, and dispatch preferences. Use this page to look up who covers a market, what they charge, and how they should be prioritized for dispatch.

Technician Information

Los Angeles

San Diego

Glass suppliers & warehouses (San Diego / LA region)

Phoenix

Technician Documentation & 1099 Requirements

• When a new technician is used for 3 jobs, obtain a completed W-9 from the technician.
• If the W-9 is missing after the 3-job threshold, flag it for review before assigning additional work.
• If a technician keeps refusing to provide their W-9/1099 info after being asked, remove them from the active technician roster rather than continuing to assign them jobs.
• Blank W-9 form: irs.gov/pub/irs-pdf/fw9.pdf
• Completed W-9 forms are filed in the AGLA Techs W9 forms Drive folder: drive.google.com/drive/folders/1wpfdS7u2xugOFLskm904J1qGv1_vqwEZ

SSNs/TINs are never recorded on this wiki — they live only in the W-9 forms themselves, inside the Drive folder above. Look them up there, not here.

Status by tech

Dispatch Priority & Reliability Ranking

This section requires team input from Alex/Celia/Nico.

Los Angeles

San Diego

Phoenix

How to create a new tech in Admin → Employees — fields to fill in, what to skip, and the calendar-color trick.

New techs (and any other staff) are created under Admin → Employees → New Employee.

Steps

1. Go to Admin → Employees → New Employee.
2. Under Job functions, check Technician. This unlocks the Tech Details panel on the right (entity, pay rates, scheduler settings) — leave it unchecked and that panel stays hidden.
3. Leave Can login off. Techs don't need dashboard access — only staff who log in need a password and a role.
4. Fill in, in this order:
   1. Name
   2. Phone
   3. Calendar color — see below, this one takes an extra step.
   4. Tech Details → Fixed cost per job (their standard flat rate) and Luxury car rate (flat rate paid instead of the fixed cost when a job is marked luxury).
   5. Zelle payout name — exactly as it appears in Chase (e.g. "Zelle payment to Jose Aguirre" → enter "Jose Aguirre"). This is what auto-matches their End-of-Day payouts on the bank ledger — get it right or reconciliation won't match automatically.
5. Leave End-of-day summary texts and AI scheduling texts off for most new techs. Only turn these on if the tech has specifically been set up for nightly pay-summary texts or AI-negotiated scheduling — don't enable by default.
6. Set Entity (location) under Tech Details to whichever location the tech works for.
7. Click Create (or Create & create another if you're adding several in a row).

Picking a calendar color

Each tech's calendar color needs to be unique so appointments are visually distinguishable — but the create form doesn't show you which colors are already taken.

Before picking a color:

1. Open the Employees list (or the scheduling calendar) in another tab.
2. Scan the existing techs' calendar colors.
3. Pick a color that's visibly different from all of them — don't reuse a near-duplicate shade (e.g. two similar blues). When in doubt, go with a color further around the color wheel from whatever's already there rather than a lighter/darker variant of an existing one.

If the dashboard ever grows a "list all used colors" view, use that instead of eyeballing the Employees list — check the Technician Directory or Employees list for the current roster first.

What to leave alone

• Preferred language, Active (defaults to on), and job functions other than Technician — only touch these if the tech specifically needs them.
• Don't turn on Can login for a tech unless they've been explicitly approved for a dashboard account and role (see roles).

How the AI scheduling tool negotiates a job's time slot with technicians over text — session setup, ranking, negotiation, booking, and dispatcher controls.

"Schedule w/ AI" negotiates a job's time slot with technicians over text, one at a time, instead of a dispatcher calling/texting each tech by hand. It only ever settles the date/time and which tech — everything else about the job (distance pay, warehouse changes, other schedule checks) stays with a person.

The flow

flowchart TD
  START["Dispatcher clicks 'Schedule w/ AI'<br/>(job view or Send Welcome screen)"] --> SETUP[Review/edit window, time type,<br/>warehouse, tech order, mode]
  SETUP --> BUILD[System builds ranked tech list<br/>opted-in only, filtered by day-part load & conflicts]
  BUILD --> TEXT[Text top technician an offer]
  TEXT --> REPLY{Technician reply}
  REPLY -->|Accept| BOOK
  REPLY -->|Counter — fits window| BOOK
  REPLY -->|Counter — doesn't fit| RETRY["Ask same tech once more"]
  RETRY -->|Still no fit| NEXT[Move to next technician]
  REPLY -->|Decline| NEXT
  REPLY -->|Question, before any yes| PAUSE[Stop — dispatcher steps in]
  REPLY -->|Question, after a yes| BOOK
  REPLY -->|Emoji / ambiguous| CONFIRM["Read the meaning back<br/>before booking"]
  CONFIRM --> BOOK
  NEXT --> TEXT
  BOOK{"Still open?<br/>Not already scheduled by a person?"}
  BOOK -->|Pass| WRITE[Write tech/date/time via normal scheduling]
  WRITE --> CARDTXT[Text tech full job card]
  WRITE --> CUSTTXT[Text customer time confirmation]
  WRITE --> TG[Post one alert to Telegram]
  WRITE -.->|No warehouse set| ASKWH["Ask tech which warehouse, after booking<br/>never blocks or cancels the booking"]

1. A dispatcher starts a session

Open a job → Schedule w/ AI. This button lives on the job view and on the Send Welcome screen. Before starting, the dispatcher reviews/edits:

• Date/time the customer wants — pulled from intake, editable.
• Time type — exact time, part of day, after a time, before a deadline, or any time (see The four time types).
• Warehouse for the part — can be left empty.
• List of technicians to contact, in order — drag to reorder.
• Mode:
  • Simulate — no real texts send.
  • Approve — a person must click send on each text.
  • Live — the system sends texts on its own.

2. The system builds the technician list

• Only technicians opted in for AI texts are contacted.
• A technician is skipped if they already have two jobs in the same part of the day (morning/afternoon/evening), or if they're busy on a job at the same exact time.
• Technicians with room in their day are ranked first.
• Two separate rank lists exist — normal cars and luxury cars. The system uses whichever list matches the job's vehicle.

3. The system texts technicians, one at a time

The top-ranked technician gets a text offering a time slot. If they don't reply in time, the system moves to the next technician on the list. Possible replies:

Warehouse pushback: if a specific warehouse is already set on the job, the first text tells the technician the pickup location. If the technician pushes back, the system replies once with a firm answer — it does not change the warehouse without a person's help.

4. The system books the job

Before booking, it re-checks the job is still open and that no person has already scheduled it elsewhere. If both checks pass:

1. Writes technician, date, and time to the job through the normal scheduling process.
2. Texts the technician the full job card — customer name, phone, address, time, vehicle, part number, warehouse.
3. Texts the customer the normal time-confirmation text.
4. Posts one alert to the Telegram group so a person can check the booking.

If no warehouse was set going in, the system asks the technician which warehouse to use after booking — that question never blocks or cancels the booking.

5. Dispatcher controls during a session

The AI Scheduling page shows texts live as they happen. A dispatcher can:

• Pause / resume the session
• Skip the current technician
• Cancel the session
• Take over and finish the booking by hand

The four time types

What the AI scheduler does NOT do

• Distance pay never comes up. The AI never asks about it and never books it. A dispatcher can add distance pay after the AI books the job, up until the job's start time — this keeps the negotiation focused on the time slot only.
• Only the two-jobs-per-part-of-day check runs inside the AI scheduler's search. Other checks — part-vs-glass mismatch and the OEM parts deposit — are not checked inside the AI scheduler's own flow. They still show up later if a dispatcher opens the manual Schedule or Reschedule screens for the same job.

The weekly bank reconciliation, Accounts Receivable checks, and the ROAS report.

Bank ledger (Plaid → Chase)

Chase checking + credit-card transactions are pulled automatically every morning into the read-only Bank Transactions ledger (Admin area). Balances show at the top — checking, credit-card owed, and net cash position. Cash never appears here by definition — it's tracked through tech balances.

Weekly SOP — reconcile the bank

Goal: every Chase transaction gets accounted for. The auto-matcher does most of the work; the team confirms and fills gaps.

flowchart TD
  PULL[Daily automatic pull + auto-matcher] --> TAB[Open Bank Transactions<br/>Needs review tab]
  TAB --> SUG{Suggested match shown?}
  SUG -- Yes --> OK["Confirm it (one click)"]
  SUG -- No --> MAN[Match manually:<br/>job payment / part purchase / tech payout / misc]
  OK --> ZERO{Badge at zero?}
  MAN --> ZERO
  ZERO -- No --> TAB
  ZERO -- Yes --> DONE[Week reconciled]

1. Open Bank Transactions — it lands on the Needs review tab (badge = open items).
2. Confirm each suggested match (✓). Suggestions only appear when there's exactly one candidate, so they're safe to trust — but glance at them.
3. Match the rest manually: pick the kind —
   • Job payment — incoming Zelle/CC → the job's customer payment
   • Part purchase — vendor charge → the job(s) it was for (one charge can cover several)
   • Tech payout — outgoing Zelle → that day's End-of-Day payout (matched on the net amount)
   • Misc — Google Ads, card autopay, bank fee, transfer, refund, other
4. Repeat until the badge hits zero. Unmatch undoes any mistake.

Accounts Receivable (admin-only)

Admin → Finance → Accounts Receivable shows two buckets — work through both regularly:

• Awaiting payment — work is complete but no payment recorded. Action: Record payment. Stripe payments don't need this — the dashboard auto-records them the moment Stripe receives the charge, deposits included. This only applies to Stripe; Zelle, Venmo, and cash are still recorded by hand.
• Collected · unconfirmed — a non-cash payment (Zelle/Venmo/Stripe) was recorded but hasn't been verified against the bank yet. It clears automatically when the bank reconciliation matches it, or hit Confirm received if you've verified it by hand.
• Cash is always considered confirmed (the tech-balance system tracks it).

ROAS report

Weekly per-location: Ads spend + leads vs booked revenue & profit (revenue = job quote; profit = quote − part cost − tech pay; attributed to the week the job was created; lost/canceled excluded). Ad metrics pull automatically every morning from Google Ads.

Caveats to remember when reading it:

• Insurance jobs understate revenue — the quote is just the deductible; the carrier's payment isn't counted (by design, for now).
• If ad metrics stop updating, the Google OAuth token likely expired — flag to Alex/Claude.

How automated texts work — providers, templates, the review drip, receipts, and STOP handling.

How texting works

• Every outgoing text goes through one outbox — messages are queued, sent by a background worker, and idempotent: an automated step can never double-send.
• The active SMS provider is chosen at runtime in Admin → Integrations & API Keys:
  • Quo / OpenPhone — primary. Their inbox is deep-linked from jobs (the "Call" button).
  • Podium — sends from the Podium location's own number (also used by the website lead flow).
  • RingCentral — available as an alternative.
• Inbound texts land in Operations → Incoming Texts.
• Outgoing texts can be paused globally; outside production everything logs instead of sending — so tests never text real customers.
• STOP: if a customer texts STOP (or is manually opted out), their live review drips are canceled and unsent messages are dropped automatically.

Message templates

Every automated text is editable under Message Templates — reminders, payment requests (Zelle/Venmo), review drip, receipt, warranty visit. Templates use merge variables like {first_name}, {google_review_url}, {amount_paid}. Templates that require a variable refuse to queue until it's available (e.g. review asks won't send until the entity's Google review URL is set under Admin → Entities).

The review drip

Started by the 👍 answer to "How did the job go?" when recording payment. State machine, managed on Operations → Reviews (the nav badge = drips waiting on a call):

flowchart TD
  PAY[Payment recorded + thumbs up] --> T1[Text 1: review request — sent now]
  T1 --> T2[Text 2: follow-up — next day, 10:00 AM]
  T2 --> CALL{Manual step: call the customer<br/>then Log call on the Reviews page}
  CALL -- Voicemail --> T3[Voicemail follow-up text — sent now]
  CALL -- Connected --> CHOICE{Send after-call text?}
  CHOICE -- Yes --> T4[After-call text]
  CHOICE -- Not interested --> END1[Drip canceled]
  T3 --> T5[Final text — 7 days later]
  T4 --> T5
  T5 --> END2[Drip completed]
  ANY[Customer leaves a review<br/>at any point] --> TY[Mark Review left →<br/>thank-you text, drip ends]

Working the Reviews page

• Log call (after text 2): choose voicemail (fires the voicemail text) or connected (choose after-call text or "not interested").
• Review left: any time you spot a new review from a customer, mark it — sends the thank-you text and ends their drip.
• Pause / Resume / Cancel per customer as needed.
• 👎 jobs are kept on record but never text the customer.
• Skip for later instead of logging the first call is fine — it just leaves the job waiting.
• If nobody logs a call by 7pm the same day, the system logs it as 👍 for you and starts the text sequence anyway — a busy afternoon never loses the review request.
• Calibration jobs are the one exception: the review request waits until ops confirms the calibration, not until the windshield install itself is complete. See ADAS calibration jobs.

Receipts

On-request only. A paid job's actions menu → Send receipt → preview → texts the receipt template with the amount, method, and date. Repeatable if the customer asks again.

How BCB Glass Ops ships — push to master IS the deploy. Plus the quick failure decoder.

The ops dashboard deploys completely differently from the marketing sites — don't mix the two models up.

The model

flowchart TD
  DEV[Make the change<br/>Claude Code, cloud clone] --> COMMIT[Commit on master]
  COMMIT --> PUSH[Push to origin master]
  PUSH --> GHA[GitHub Action runs the full deploy<br/>code + migrations + caches + queue restart]
  GHA --> HEALTH[Automatic health check on the login page]
  HEALTH --> LIVE[Live on Cloudways]

• One branch: master. That's it. No staging, no main, no feature branches — this is an internal tool with no preview tier. This rule is absolute, even for automated agents: if a session lands you on any other branch, switch back to master before committing.
• Push = deploy. The GitHub Action ships every push to master (or run it manually from the Actions tab: "Deploy to Cloudways").
• Always push live. The owner doesn't review dashboard changes before they ship — commit and push without asking.
• Commit before deploying — the deploy ships the committed state; uncommitted changes don't go live.
• The deploy never deletes server files — files removed from git stay on the server until removed by hand.
• Fallback if the Action is down: ./deploy.sh from a dev machine (dry-run by default; --live to ship), or Cloudways' "Deployment via Git → Pull" + the artisan commands by hand.

Ground rules that keep prod healthy

• Timezone: the app stores UTC and displays Pacific. Never change the app timezone — reminders will go out an hour off.
• Cache/sessions/queue all run on the database — Redis is intentionally not used, and file-based cache breaks under the server's permission model. Don't "optimize" this.
• Texts only really send in production with sending unpaused; everywhere else they log.

Quick failure decoder

The GBP SOP — one-time foundation setup, plus the weekly and monthly cadence that keeps every profile ranking.

Every location's Google Business Profile (GBP) is a top local-ranking lever. Set the foundation once, then keep the weekly and monthly cadence — consistency is what moves the map pack.

One-Time Setup (Foundation)

Done once, but reviewed periodically.

1. Business description — 750–1000 characters. Naturally include main services + location keywords (e.g. "LA Fence Experts provides affordable fence installation and repair in Los Angeles County"). Avoid keyword stuffing.
2. Cover photos & logo — upload a clean, square, high-resolution logo. The cover photo should represent the brand/service (finished projects, team photo, storefront). Add 5–10 more photos of work, team, and customers (with consent). Always use different photos per GBP — even when two profiles are in the same industry, never reuse the same photo across them; Google can flag the duplication and it risks hurting both profiles' SEO.
3. Services & products — minimum 10 services and 10 products, each with detailed descriptions, photos, and pricing where possible. Optimize with local + service keywords.
4. Booking section — enable the appointments/booking link if applicable; point it at the calendar, CRM, or booking form.
5. Categories — choose 1 primary category (the most profitable), then add 2–3 secondary categories covering additional services.
6. Business hours — set accurate hours, including holiday/special hours, at initial setup only. Do not edit hours on a live profile afterward — see the warning above.
7. NAP consistency (Name, Address, Phone) — must match the website, citations, and every online directory at setup. Keep formatting identical everywhere (e.g. "St." vs. "Street"). Phone and address are never edited on a live profile (warning above) — if a mismatch turns up later, flag it instead of editing it directly.

Weekly Tasks (Engagement)

Consistency is key.

1. Upload photos & videos — add 3–5 new photos and at least 1 video each week. Geotag media with the service location (city/area). Focus on before/after work, the team in action, and customer testimonials. Use different photos on every GBP, even for profiles in the same industry — never upload the same photo to more than one profile.
2. Respond to reviews — reply to all reviews within 48 hours using keyword-rich responses ("Thanks for choosing us for your Pasadena fence installation!"). Encourage more reviews by sending customers direct review links.

Monthly Tasks (Growth)

Long-term authority building.

1. GBP posts (keyword/location rich) — post 1–2 times per week, reviewed monthly to keep the cadence consistent. Mix offers, updates, educational posts, and case studies. Always include a CTA + location/service keywords. Schedule with the Postamatic Chrome extension from the Owner Operated Google account.
2. Citations — add or update the NAP on 10–20 new directories monthly (local business directories, industry-specific sites, Yelp, Angi, Houzz, Thumbtack, etc.). Formatting must be identical everywhere.
3. Audit the profile — check for changes made by Google or users (they sometimes edit info). Refresh photos and the cover image, and review analytics.

Good practice examples

Quick ✅/❌ reference for the sections CSRs write copy for most often.

Business description

• ✅ "LA Fence Experts provides affordable fence installation and repair in Los Angeles County, including Pasadena, Glendale, and Burbank. Our licensed crews install wood, vinyl, and chain-link fencing, plus fast repairs for storm and wear damage. We back every install with a workmanship warranty and same-week estimates."
• ❌ "We are the #1 best fence company in LA! Fence fence fence installation fence repair fence Los Angeles fence Pasadena fence Glendale!" — keyword stuffing reads as spam and can suppress ranking instead of helping it.

Services & products

• ✅ "Vinyl Fence Installation — Durable, low-maintenance vinyl fencing installed in 1–2 days, serving Pasadena and the greater San Gabriel Valley. Includes a 10-year material warranty."
• ❌ "Fence stuff" or a service with no description at all — thin/blank listings don't help local ranking and look unfinished to customers comparing profiles.

Photos

• ✅ Real before/after shots of a completed job, geotagged to the job's city, a technician actively working, a happy customer next to the finished work (with their consent).
• ❌ Stock photos, a screenshot of the website, or the exact same photo set uploaded to a sister GBP in another city — duplicate images across profiles are a red flag to Google.

Review responses

• ✅ "Thanks so much, Maria! We're glad our Pasadena crew could get your fence replaced so quickly. Reach out anytime if you need anything else." — genuine, names the customer, naturally works in the service + city.
• ❌ "Thank you for your 5 star review of our fence installation and repair services in Pasadena Glendale Burbank Los Angeles." — reads like a bot stuffing keywords, not a reply to a person.

GBP posts

• ✅ "Storm season is here — if your fence took wind damage this week, we're offering free repair estimates in Pasadena through Friday. Tap below to book a same-week visit." — timely, has a clear CTA, reads like a real update.
• ❌ A generic "We do fence installation and repair!" post with no offer, date, or CTA, reposted unchanged month after month.

AI prompts for CSRs

Ready-to-copy prompts CSRs can paste into the team's AI assistant to draft GBP copy. Always fill in the bracketed details, and read the output before posting — treat it as a strong first draft, not a finished, approved copy.

Business description

You're an SEO expert who specializes in optimizing Google Business Profiles for local service
businesses. Write a Google Business Profile business description for [Business Name], a
[industry/service type] company serving [city / service area, list neighborhoods if relevant].

Requirements:
- 750–1000 characters
- Naturally include our main services: [list services]
- Naturally include our service area/location keywords: [list cities/neighborhoods]
- Written in a natural, human tone — no keyword stuffing, no "#1 best" claims
- End with a soft call to action
- No quotation marks, no emojis, no generic filler like "we are a leading company"

Services & products descriptions

You're an SEO expert writing Google Business Profile service and product listings for
[Business Name], a [industry/service type] company serving [city / service area].

For each service/product listed below, write a description between 150–300 characters that:
- Naturally includes the service name plus one or two location keywords
- Highlights a specific, concrete benefit to the customer (not generic praise)
- Sounds human and conversational, not robotic or stuffed with keywords

Return the output as a list, one description per line, matching this order:
[paste the list of services/products]

GBP posts

You're an SEO expert writing a Google Business Profile post for [Business Name], a
[industry/service type] company serving [city / service area].

Write a [offer / update / educational / case study] post that:
- Naturally mentions [service] and [city/area] as keywords
- Includes a clear call to action
- Stays under 1500 characters
- Sounds friendly and local, not salesy or generic

Context for this post: [describe the offer, update, or story]

Review responses

You're an SEO expert writing a reply to a Google Business Profile customer review for
[Business Name], a [industry/service type] company in [city].

Here is the review: "[paste the customer's review text]"

Write a reply that:
- Is under 350 characters
- Thanks the customer by name if one is given
- Naturally mentions [service performed] and [city/area] as keywords
- Sounds warm and genuine — not templated, not robotic, no keyword stuffing

The global rules — two deploy models, branch discipline, and what "push" vs "deploy" means.

We run two deploy models. Knowing which one you're in prevents 90% of mistakes.

Changing a marketing website?

flowchart TD
  A1[Branches: main + staging ONLY] --> A2[Work on staging → verify the preview]
  A2 --> A3[Owner approval for customer-facing changes]
  A3 --> A4[Merge to main = PRODUCTION deploy]

Changing the ops dashboard?

flowchart TD
  B1[Branch: master ONLY] --> B2[Commit + push = deploy]
  B2 --> B3[No approval gate — internal tool, always push live]

The rules

1. Marketing sites: exactly two branches — main + staging. Never create any other branch (no feature/fix/throwaway branches). They drift and cause mistakes; delete strays on sight. main is the source of truth; staging is always a clean copy of it.
2. Ops dashboard: exactly one branch — master. Push to it and it deploys. Absolute rule, including for automated agents.
3. Pushing a marketing site's main is a live production deploy — verify on the staging preview first, and get explicit approval for customer-facing changes. "Push to staging" never implies production.
4. The dashboard is the opposite — always push live, no review step. It's internal.
5. GitHub is the source of truth. All repos live under the OwnerOperated account. Local clones live under C:\Users\alexb\Glass projects\.
6. Local first — never edit production servers directly. Everything goes through git so the repo stays authoritative.
7. Never commit build output — no dist/, no node_modules/. The platforms build from source.

Verb glossary

Working with Claude Code

• Open Claude in the specific repo's folder so its rules file (CLAUDE.md) auto-loads — never work from the home directory.
• On launch, a sync-check reports whether the local clone is [UP TO DATE] or [BEHIND] the remote — never work on a stale copy.

Where credentials live, where they never go, and who gets access to what.

The one rule

No credential ever goes in a committed file, a chat log, or this wiki. If you're about to paste a password, an API key, or a token somewhere — stop and check this page.

Where secrets live

The committed CLAUDE.md in each repo = operational rules only, never credentials. That split means the safe half is in git and the sensitive half never leaves the machine/server.

Access

• Wiki: viewing should be gated with Cloudflare Access (email-based login) once live — it's an internal manual. Editing requires a GitHub account with access to the bcb-wiki repo.
• Dashboard: role-based — super_admin / admin / dispatch / finance. Give people the lowest role that does their job (dispatchers get dispatch, bookkeeping gets finance). Only a super_admin can grant elevated roles. See the roles table.
• GitHub: repos are private under OwnerOperated. Collaborators get added per-repo.

Rotating / fixing credentials

• Dashboard webhook signature errors → re-paste the signing secret in Admin → Integrations & API Keys.
• Podium tokens are per Cloudflare Pages project — when rotating, update every site project and redeploy each one (env vars bind only on a new deployment).
• If Google Ads metrics stop pulling, the OAuth refresh token likely expired — regenerate and re-save in Integrations.