ABKC Admin Walkthrough — Office Manager Edition (V1)

Audience: the ABKC Office Manager — the person who owns the paperwork, runs the computers, trains every office worker, and is the answer-of-last-resort for anyone who calls the ABKC. Written train-the-trainer style: every module teaches you the clicks, then tells you what to teach your staff, then gives you the phone script.
Secondary audience: ABKC ownership + Dane Cooper (system owner) + the standing deliverable panel (engineering, security, legal, QA, payments/PCI, privacy/COPPA, accessibility/WCAG 2.2, SRE).
Version: V1 · 2026-06-09 · companion to the ABKC payment walkthrough package (INDEX.md in this folder).
Canonical source: this Markdown; HTML (interactive) / PDF / DOCX are derived — regenerate per §10.
Time: ~45 min to read · ~90 min to execute all modules once · 2-week staff-training plan in §6.

§0 — Scope: what you run, what you escalate

This walkthrough covers the ABKC admin area (/admin) for daily office operations: the registration queue, approvals and ABKC-number assignment, the "I paid but got no certificate" triage, co-owner signature chasing, shop orders, member lookup, and the audit trail. It is the training backbone for your staff — everyone who answers an ABKC phone or email works the workflows in this document, and they answer to you.

Where the admin area lives today: https://abkc-website.vercel.app/admin. After ABKC ownership authorizes the DNS cutover, the same screens will be at www.abkcdogs.com/admin — bookmarks change, nothing else does.

Out of scope (V1): dog-ownership transfers (the /admin/transfers screen exists but is NOT READY — do not train or promise it), content publishing (magazine/articles/homepage — reference appendix only), and anything in the §8 escalation column (those go to Dane).

Status legend you will live in

§1 — Pattern + Triple Verification Protocol

This document follows the estate Tutorial Template v2 (17 sections, exactly 4 diagrams, interactive HTML build, honest reservations, sign-off). Claims were verified 2026-06-09:

🧭 Interactive HTML: open ABKC-ADMIN-OFFICE-MANAGER-WALKTHROUGH-V1-2026-06-09.html in Chrome/Edge. Checkboxes persist per-browser; the 📝 notes panel auto-saves (use it for your training notes per staff member); the progress bar tracks your module completion.

§2 — Prerequisites + accounts + roles

• [ ] A computer with Chrome or Edge (the office standard browser — pick one and train on it).
• [ ] Your ABKC member account (the same login members use) — created at https://abkc-website.vercel.app/signup if you don't have one.
• [ ] Dane has granted your account the office role (he does this once at /admin/users). The system admits three roles to the admin area: admin (Dane), office (you + staff), and rep. Office is deliberately not full admin — least privilege protects you as much as the system.
• [ ] You can reach https://abkc-website.vercel.app/admin and see the dashboard (if you see "Access Denied", your role isn't set yet — ask Dane, that's the only fix).
• [ ] For M4 (payment triage) you'll want read access to the Stripe dashboard and PayPal dashboard — Dane invites you with view-only permissions; never share those logins with staff.

Training rule of thumb: staff get the office role only after they've passed your M2+M3 sit-along (the §17 trainer log records this).

§3 — Diagram 1/4: the system from the office's seat

§4 — Diagram 2/4: the approval, click by click

§5 — Diagram 3/4: the phone-call decision tree

§6 — Diagram 4/4: the two-week staff-training plan

§7 — Modules M1–M3: sign-in, the queue, and decisions (the core)

M1 — Sign in, know your role, respect the audit trail (~10 min)

Your clicks
- [ ] Go to https://abkc-website.vercel.app/login → sign in → then open https://abkc-website.vercel.app/admin.
- [ ] Confirm the dashboard loads (no "Access Denied"). Bookmark it as ABKC ADMIN.
- [ ] Open /admin/audit-log once, just to see it: every approve/reject/role change is recorded with who + when + what changed. You never need to reconstruct "who did this" from memory.

Teach your staff: one account per person, never share logins — the audit trail is per-person and it protects them ("I didn't do that" is checkable). Lock screens when stepping away (members' personal data is on screen — names, addresses, emails).

Phone script: none — this module is hygiene.

(capture during execution)

M2 — Master the registration queue (~15 min)

Your clicks
- [ ] Open /admin/registrations. Read the status badges (legend in §0) and the validation dot on each row: green = data checks pass · amber = warnings · red = something failed validation (e.g., a missing dam ABKC number).
- [ ] Filter to submitted — this is the work pile; everything else is either waiting on the applicant or finished.
- [ ] Click a row → the detail page: owner info, dog details (breed, sex, DOB, color, microchip, sire/dam), the four uploaded documents (pedigree front, complete pedigree, two photos), any add-ons (e.g., rush processing), and the fee breakdown (single-dog example: $62.00 = $55 base + $7 processing).
- [ ] Open every uploaded PDF/photo once. You are checking: legible? the right document? matches the form data (dog name, sire/dam)?

Teach your staff: the queue is worked oldest-first within submitted unless a rush add-on says otherwise; the validation dot is a hint, not a verdict — red flags get a human look, not an auto-reject.

Phone script — "Is my dog registered yet?": ask for the owner's email or the dog's name → filter the queue → read the badge honestly: "You're in the queue — submitted on [date], we're working applications from [date] right now." Never promise a specific day; promise the next status email.

(capture during execution)

(capture during execution)

M3 — The five decisions (and what each one emails) (~15 min)

From the detail page you have five buttons. Every one of them writes the audit log; three of them email the applicant.

What the buttons are actually labeled on the page (so you're not hunting for one called "Approve"): approving is two clicks — first "Mark Under Review" (claims it as yours), then "Auto-Assign Number", which assigns the next ABKC number and approves it in one step. To use a specific number instead, type it in the override field next to it. There is no single button literally labeled "Approve" — "Auto-Assign Number" is the approve. ("Mark Under Review", "Request Revision", "Return", "Reject", and "Reopen" are labeled exactly as in the table above.)

Your clicks (do one real approval end-to-end)
- [ ] Pick a clean submitted application → click Mark Under Review → then Auto-Assign Number (it assigns the next ABKC number for you), or type a specific number in the override field. (Dane sets the numbering scheme — record it in the 📝 notes panel.)
- [ ] Watch the badge flip to green approved.
- [ ] Verify the packet email went out: ask the applicant once, or check the email log if you have Resend access. The PDFs are generated and attached automatically — you never make certificates by hand.
- [ ] Try a Request Revision on a flawed application and read your own note back as the applicant will read it before sending.

Teach your staff: the note fields are customer-facing email copy — kind, specific, one ask per note ("Please re-upload the complete pedigree — page 2 was cut off"), never internal shorthand. Reopen exists (approved/rejected → under_review) for genuine mistakes; using it is normal, hiding a mistake is not.

Phone script — "I made a mistake on my application": "No problem — I'll send it back to you for revision right now; you'll get an email with exactly what to fix, you resubmit, and it comes straight back to the front of my screen." (Then actually click Request Revision while they're on the phone.)

(capture during execution)

§8 — Modules M4–M8: triage, signatures, shop, people, escalation

M4 — "I paid but never got my certificate" (the triage that earns trust) (~10 min)

The system finishes paid registrations through three independent paths — a Stripe webhook, a PayPal webhook, and a scheduled backstop that sweeps for anything the webhooks missed. So "paid but stuck" is rare and almost always one of these four, in order:

• [ ] 1. It's simply in the queue — status submitted: tell them where they are (M2 script) — payment fine, paperwork pending you.
• [ ] 2. Approved, email missed — status approved: have them search their inbox and spam for the ABKC sender; confirm the email address on the application is the one they're checking; fix a typo'd email by Request Revision (they correct it) or escalate for an address correction + resend.
• [ ] 3. Paid on the processor, not advanced here — they have a PayPal/Stripe receipt but the application isn't submitted yet: the backstop sweep usually clears this within the hour. If it's older than a day, screenshot the detail page + their receipt → escalate to Dane (this is a payment-row mismatch, not an office fix).
• [ ] 4. No payment at all — they think they paid but the processor shows nothing: walk them back to their account to complete checkout; never take card numbers by phone (we are never the ones touching card data — that's the whole PCI point).

Teach your staff: the order matters — check our queue before doubting the member's payment. The phrase that de-escalates: "Your payment is safe — let me find exactly where your application is."

(capture during execution)

M5 — Co-owner signatures: status + resend (~8 min)

Registrations with a co-owner can't finish until every listed co-owner signs (they do it at their own account → Pending signatures → draw the signature on screen → submit).

• [ ] On a co-owner application's detail page, find the signature status (invited / signed / declined / expired).
• [ ] If a co-owner "never got it": confirm their email, then resend the invitation. Heads-up (V1): a one-click "Resend invite" button may not be live on the detail page yet — if you don't see it, send Dane the application link + the co-owner's correct email and he'll re-send it. Invitations expire after 14 days — resending is routine, not an error.
• [ ] Know the friction: the co-owner needs an ABKC login of their own (a brand-new co-owner gets an invitation to create one first). That's the #1 reason for "I clicked the link and nothing worked."

Phone script — "My co-owner never got the email": "I'll resend it right now — have them check spam, and one important thing: they'll need their own free ABKC login to sign; the email walks them through it."

(capture during execution)

M6 — Shop orders, lightly (~5 min)

• [ ] Open /admin/orders (order history) and /admin/products (inventory) — read-only awareness for V1: you can answer "did my order go through?" by finding the order row.
• [ ] Anything about refunds, shipping problems, or inventory changes → §8 escalation (V1 trains lookup, not fulfillment).

M7 — People: members, duplicates, roles (~7 min)

• [ ] /admin/users — find a member by name/email; this is also where roles live. Policy: only Dane grants or changes roles — you verify ("yes, your account is set up"), he grants.
• [ ] /admin/identity-resolver — awareness only: when one human ends up with two accounts (typo'd email signup), this screen exists to merge them; flag candidates for Dane rather than merging yourself in V1.

M8 — Escalation matrix + the two logs (~5 min)

• [ ] Bookmark /admin/audit-log + /admin/error-log; staff use them read-only.

Reference appendix (exists; not trained in V1): events · judges · clubs · records · link-dogs · articles · magazine · library · faq · newsletter · media · homepage · design-tokens · verification · migration · settings · transfers (NOT READY — do not use)

§9 — Owner-decision blanks (Dane completes these before training day)

These are policy questions the software can't answer — fill them in ink before the first staff session:

§10 — Reference card

Admin home ............ https://abkc-website.vercel.app/admin
Queue ................. https://abkc-website.vercel.app/admin/registrations
Users / roles ......... https://abkc-website.vercel.app/admin/users
Orders / products ..... https://abkc-website.vercel.app/admin/orders  /admin/products
Audit log / errors .... https://abkc-website.vercel.app/admin/audit-log  /admin/error-log
Member login .......... https://abkc-website.vercel.app/login
Co-owner signing ...... member account -> Pending signatures
Single-dog example .... $62.00 total ($55 base + $7 processing)
Statuses .............. submitted -> under_review -> approved | revision_requested | returned | rejected
Packet email .......... certificate + pedigree + receipt PDFs, sent automatically on Approve
Roles ................. admin (Dane) | office (you + passed staff) | rep
Golden rules .......... one login per person | notes are customer emails | never take card numbers
After DNS cutover ..... same paths under www.abkcdogs.com (re-bookmark)

Regenerate this document's formats (from this folder):

$env:PYTHONUTF8=1
C:\Users\dcoop\.venv\Scripts\python.exe C:\Users\dcoop\scripts\generate-tutorial-html.py ABKC-ADMIN-OFFICE-MANAGER-WALKTHROUGH-V1-2026-06-09.md ABKC-ADMIN-OFFICE-MANAGER-WALKTHROUGH-V1-2026-06-09 --title "ABKC Admin Walkthrough - Office Manager Edition (V1)" --slug abkc-admin-office-v1

§11 — UI anatomy: the two screens you'll teach most

The queue (/admin/registrations): left-to-right — dog name / applicant / status badge (color legend §0) / validation dot (green-amber-red data check) / submitted date. The filter bar above pins your working set (submitted). Row click opens the detail page.

The detail page (/admin/registrations/[id]): top = applicant + dog identity block · middle = the four documents (open each in a tab) + add-ons + fee breakdown · bottom = the action row (Approve with the ABKC-number field, Under Review, Request Revision, Return, Reject — and Reopen on closed items) · co-owner block with signature statuses + Resend when applicable. The note box under Revision/Return is the email the applicant receives.

(capture during execution)

(capture during execution)

§12 — Verification: how you know a trainee is ready

§13 — What's next (after your first solo week)

You: run the two-week plan (§6) · fill the §9 policy blanks with Dane · keep a running 📝 notes export per staffer for the §17 log.
Dane: grant office roles as staff pass · the co-owner member walkthrough (companion doc, same folder) covers the member-side signing experience your callers see · transfers admin + printed-certificate program are future system work, not office promises.
System (already automatic): payment webhooks + the scheduled backstop + packet-email fulfillment + audit logging — none of it needs office hands.

§14 — Anchors + deep links (verified 2026-06-09)

The screens you'll use: admin home · registrations · orders · products · users · identity-resolver · audit-log · error-log · member login · signup · the public registration form

Appendix screens: events · judges · clubs · records · link-dogs · articles · magazine · library · faq · newsletter · media · homepage · settings

Vendors + standards: Stripe dashboard · Stripe receipts · PayPal sign-in · PayPal help center · Resend docs · Supabase Row Level Security · Supabase status · ShareX (screen capture) · PCI SSC quick guide · WCAG 2.2 · Vercel docs

(24 product deep-links + 11 vendor/standard anchors = 35 total — machine-counted)

§15 — Glossary (46 terms, office language)

§16 — Honest reservations

1. Screenshots are capture-during-execution — the screenshots/admin-*/ images don't exist until your first run; capture them then (they make staff training dramatically faster).
2. Mermaid diagrams render as code text in the DOCX build (known generator limitation); use the HTML or PDF for training.
3. Transfers admin is NOT READY — the screen exists but isn't wired; promising transfers on the phone is the one guaranteed way to create an angry caller.
4. Dual co-owner (sire + dam) sequential signing is unproven in the UI — single co-owner flow is solid; if a litter application shows two co-owner rows, treat as M4-style escalation until Dane validates it.
5. Physical certificates don't exist — fulfillment is digital-only (a 2026-05 ownership decision); §9 blank #4 is where that changes, not the phone.
6. Signature invitations expire silently (14 days) — nothing nags you; checking co-owner status on aging applications is an office habit, not a system feature.
7. office role sees everything — there's no per-staffer narrowing yet; your trainer log + the audit trail are the compensating controls.
8. Admin screens were verified at code level on 2026-06-09, not by an office click-through — your first M1–M8 run is the live validation; note any mismatch in the 📝 panel and it feeds V2.
9. URL changes at DNS cutover — every deep link here moves to www.abkcdogs.com; the reference card's last line is the re-bookmark reminder.

§17 — Sign-off + trainer log

Office Manager attestation: I executed M1–M8 on the live admin area, the §9 policy blanks are filled, and the verification checks in §12 are how I pass my staff.

Office Manager: ____ Date: _ Signature: _____

System owner (Dane): ____ Date: ____

Trainer log (one row per staffer)

§A — Amendments Log (append-only)

• 2026-06-09 — V1 authored by Claude Fable 5 (plan ~/.claude/plans/autonomous-loop-check-sparkling-tome.md, Dane-approved scope: core 8 modules + reference appendix, role-generic). Grounded in a same-day code-level mapping of the live admin surface (26 routes, roles admin/office/rep, approval RPC, three fulfillment trigger paths) + the 2026-05-28 payment walkthrough family. Honest flags carried per ~/.claude/rules/integrity-policy.md. Per ~/.claude/rules/archive-policy.md: append-only.
• 2026-06-16 (V1.1 corrections) — Corrections from a live read-only Playwright E2E + source verification (Dane-requested: "verify the guides + instructions are correct, test E2E so Emily doesn't hit errors"). The E2E (abkc-website/tests/e2e/office-manager-walkthrough.spec.ts, against the live site) confirmed: the office manager (admin role) reaches /admin and every admin page renders (HTTP 200, no Access-Denied / no blank); the registration queue renders but is currently empty (no rows to open, so the detail-page controls were verified from source, not live). Fixes: M3 — clarified the approve flow is "Mark Under Review" → "Auto-Assign Number" (no single "Approve" button; "Auto-Assign Number" is the approve), removing the "type number → click Approve" mismatch. M5 — flagged that a one-click "Resend invite" button may not be live on the detail page in V1 (escalate the resend to Dane if absent). Open site gaps (Identity Resolver thin; no Resend-invite UI button; duplicate input#email on /login; no dedicated paid-triage view; empty queue → seed a test registration for training) are recorded in abkc-website/.ai-notes/abkc-site-punchlist-2026-06-16.md — not changed here. Emily's account (abkcemily@gmail.com) set to the admin role this session per Dane. Per archive-policy.md: append-only.