Skip to main content

Knowledge > Products > FuneralWiseAI > Design Direction

FuneralWiseAI — Admin Dashboard Design Direction

The funeral admin command center is a port of the WiseAI Realtor design system (products/wiseai-realtor/design-direction.md is the parent spec — layout archetypes, type scale, spacing, radius/elevation, density, and the 10 anti-patterns apply verbatim). This doc records only what is FUNERAL-SPECIFIC. Approved by the founder 2026-07-02; plan of record C:\dev\PLAN_FUNERALWISE_DASHBOARD_REVAMP_2026-07-02.md.

Token mapping (realtor role → funeral value)​

RoleRealtorFuneral
Rail/chromenavy #0B1F3Aslate #1E293B, deep #0F172A
Single action colorteal #0F766Edeepened sage #3F685C (white text ~6.3:1 AA; brand #4D7C6F is tint-only), tint #EDF5F1
Highlight/celebration ONLY (never body text)gold #C49A3Acopper #B45309, tint #FEF3E2, text-on-tint #8A4A0B
Neutrals / semantic / type / spacing / radius / density—identical to realtor spec (#FAFAFA bg, #E6E8EB border, #18181B text, #6B7280 muted, Inter, 14px body, tabular-nums, rounded-2xl border-first low-shadow)
Pipeline stages (Arrangements)6 lead stagesNew inquiry=blue · Arrangements=teal · Service set=amber · Completed=green · Aftercare=violet — always label+color (AODA)

Tokens are INLINE hex in components (same convention as realtor — no CSS-variable layer yet; consolidation is a known cross-vertical lever). The serif/display fonts (Fraunces) belong to the funeral MARKETING site only — the admin stays neutral per the realtor "warmth lives in marketing" rule.

Shell (Phase 1 — PR #1106)​

src/components/admin/funeral/shell/ — FuneralShell (app frame; 248px rail collapsible to 64px, hydration-safe localStorage persist; <lg off-canvas drawer), FuneralRail (nav from FUNERAL_TABS, copper at-need badge, sage inbox badge), FuneralTopBar (copper setup-progress pill from real setup state, Ask Grace launcher, at-need bell), nav-model.ts (IA = src/lib/verticals/funeral.ts FUNERAL_TABS; contract-tested). Gated strictly on verticalProfile?.key === 'funeral' in AdminDashboard — church/vet render the legacy tab chrome byte-identically. ?tab= deep links are the compatibility contract (funeral keys must resolve against FUNERAL_TABS, not church ALL_TABS).

Grace concierge (Phase 2 — PR #1110)​

Port of Aria Phase-1 (products/wiseai-realtor Aria docs are the parent): read-only, zero write tools, deep-link screen registry over the 8 funeral tabs. Funeral-specific: grief-sensitive tone (never rushes, plain language), defer set (no legal advice, no specific prices to families, no grief counselling — 988 + "a director will reach out" AI-bridge escalation), guardrail belt src/lib/funeral/ai-guardrails.ts (audit-mode, Aria parity). Auth = admin-token resolution via resolveFuneralToken(); client-supplied tenant ids/headers are never trusted (cf. security P0 #1102). Endpoint /api/funeral/assistant, model Haiku 4.5 (GRACE_ONBOARDING_MODEL override) — runtime customer-facing carve-out, never batch.

Funeral data-layer rules (discovered 2026-07-02 — read before writing funeral queries)​

  1. church_voice_agents, voice_visitor_contacts, voice_prayer_requests are VIEWS filtered vertical='church' over tenant_voice_agents, voice_visitor_inquiries, voice_urgent_requests (views alias tenant_id AS church_id). Funeral reads/writes must use the BASE tables with tenant_id + vertical='funeral' (fix PR #1108: getTenantVoiceAgentSafe, funeral metric branch, funeral inbox).
  2. voice_callback_requests and voice_call_logs are base tables scoped by church_id = funeral_homes.id (the tenant id; premium_funeral_homes.funeral_home_id === it).
  3. moderation_violations FKs reference churches/organizations only — funeral tenant-scoped safety logging is schema-impossible today (open design item).
  4. fwa_* plans normalize to channel chat, so planIncludesVoice({plan, channel}) alone can never grant funeral tenants voice — fixed in PR #1115: getInboxStream uses inboxIncludesVoice() (church path = planIncludesVoice verbatim; funeral additionally honors hasVoiceEntitlement = active tenant_voice_agents row OR premium_funeral_homes.has_voice_subscription).
  5. Demo tenant: Moelker Family Funeral Home, London ON — funeralwiseai.com/admin/demo-moelker-7f3a, tenant e0f4a11e-f00e-4a11-b000-000000000001, all seed rows e0f4a11e--prefixed + is_demo (script churchwiseai-web/scripts/seed-moelker-funeral-demo.mjs, INSERT-only idempotent). The Kolssak tenant (demo-kolssak-51cb) is a live prospect — never use it for test data and never email them.

Daily-driver screens (Phase 3 — PR #1112)​

FuneralInboxBody (3-pane inbox: funeral filter chips as saved-view list with live counts | item list with type/urgency/status chips + copper at-need/crisis edges | detail pane with server-redacted content, Grace AI-capture labels, Mark-contacted + escalate-to-director via existing APIs), FuneralAtNeedBody (urgency-ranked list + right drawer, transcript speaker rows), PrePlanningInquiriesTab (list + drawer, next-action emphasis). No new endpoints. Data-layer rule enforced in the funeral admin routes: token resolution must scope voice_* reads/ownership checks by the TENANT id (funeral_home_id), not the premium row id — the routes accept either for legacy rows.

Acceptance specs​

  • acceptance/funeral-dashboard-command-center.md (shell + screens)
  • acceptance/grace-onboarding-concierge-mvp.md (Grace)

Verification bar: Playwright on the REAL funeralwiseai.com host (previews skip the hostname rewrite), behavioral assertions, church-token regression alongside every funeral-gated change.