mivanchenko
a04ad82e73
- Demo bars now read "Beispielseite · So könnte Ihr Online-Auftritt aussehen" (was "Tier A (Google-Stack)" / "Tier B (Self-Hosted)" / "für Gäste"). - Booking widgets relabelled generic: "Online-Terminbuchung" / "Sichere Buchung" (dropped Google Kalender + branded dots, Cal.com, self-hosted). - Removed Tier/Google/Cal.com refs from rendered copy AND HTML comments. - Demo booking dates now render on the current week via JS (no stale dates). - TODO.md: tick off completed items; add onboard back-office (Leads/Clients CRUD). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
TODO / Backlog
Rethink the tier model — decouple tier from business type
Goal: tiers should NOT be tied to a kind of business. Which "tier" (and whether a client's site is self-hosted or runs on Google's free services) is a decision made between me and the client, case by case — not something baked into a demo.
Implications to work through:
- Demos are stack-agnostic starters.
Drop tier/stack labels and jargon (self-hosted, Cal.com, Google-Stack, "≈ 0 €") from the public-facing demos & chooser.DONE 2026-06-25: chooser reworded; all three demo pages neutralised — demo bars now read "Beispielseite · So könnte Ihr Online-Auftritt aussehen", booking widgets relabelled to generic "Online-Terminbuchung"/"Sichere Buchung", Google-Kalender/Cal.com/self-hosted/Tier labels removed from rendered copy and HTML comments, demo booking dates now render on the current week via JS so nothing looks stale. - After a client signs, I decide hosting: self-host the page on the homelab, or stand it
up on the client's free Google account. The CRM already has
tier+stack_notescolumns to record that decision per client. - Revisit the
Clients.tierfield semantics: keep A/B as an internal effort/price band, or replace with something hosting-agnostic (e.g.hosting = google | selfhosted,plan = …). - Onboarding form + workflow currently ask for Tier A/B — realign once the model is settled.
Onboard dashboard → manage Leads & Clients (CRUD)
The operator onboarding page (https://onboard.mivanchenko.de) currently only creates records. Extend it into a small back-office where I can read, edit, delete and add both Leads and Clients directly:
- Read: pull and list the current
LeadsandClientsrows (via n8n webhook → Sheetsvalues.get, or Sheets API) in a clean table on the onboard page. - Add: new Lead / new Client manually (Clients add already exists via the onboarding form; add a lighter "new lead" form too).
- Edit: update a row in place (e.g. change a lead's status, fix a client's fee/renewal).
- Delete: cleanly remove a row (Sheets
deleteDimension), so test/junk rows don't pile up — replaces the current scratchpaddel_rows.py/del_lead.pymanual cleanup. - Stays behind the existing Caddy basic-auth (operator-only; these are billable/CRM records).
- Needs new n8n webhooks (list/update/delete) keyed by
lead_id/client_id.
Other
- Harden n8n auth: compose still has deprecated
N8N_BASIC_AUTH_*with passwordpassword(legacy/ignored by modern n8n owner-login). Confirm the owner account is strong; remove the dead env. - Orders: the pizzeria demo posts orders into the
Leadstab via the lead-intake webhook as a stop-gap. Build a proper Orders flow + sheet tab (items, total, mode, status) when the order-management product is real. - Booking-sync workflow (Tier-B Cal.com webhook + Tier-A Google Calendar poll).
Done
- 2026-06-25 — Latency fix (n8n executions 1–4 min → ~6 s; DNS + PostHog telemetry).
- 2026-06-25 — Chooser reworded to client-friendly, jargon-free copy.
- 2026-06-25 — Pizzeria demo with online ordering added.
- 2026-06-25 — Barbershop "Google Kalender" dot-overlap styling fixed.
- 2026-06-25 — All three demo pages neutralised (stack-agnostic, non-stale dates).