# Daily customer operations ## What it does - **Day plan:** requests waiting at least 30 minutes, overdue work, consultations awaiting outcomes, pending handoffs, today's schedule, and nurture reviews. Customer signals remain visible beside the action. - **Before you finish:** owner + dated follow-up coverage; requests waiting over four hours; overdue work without a reschedule reason; today's missed calls without a subsequent time. The review uses Malaysia dates and targets 18:00. - **Team:** accessible customer owners, specialist deadlines, handoffs, outcomes, stage deadlines, nurture proposals, missed attempts and reconfirmation. Choosing an owner or issue opens the filtered queue; choosing a customer opens the existing workflow drawer. - **Stage checks:** New/Contacted 3 days, Appointment/Consulted 7, Decision review 14. Confirmed progress restarts the window; a second missed window is escalated. Thirty days without confirmed progress proposes a nurture review. A person must still supply the park reason and revisit date. - **Portal:** a small authenticated member card shows only verified, agreed follow-up types and dates. Existing dashboard goal/planning, appointments and saved-analysis cards remain the member's other touchpoints. Staff notes, readiness, internal assessments, document identifiers and AI outputs are not sent to this card. ## How it works `DailyOperations` is a deterministic evaluator over the existing workflow input. `OperationsWorkspace` assembles viewer-safe sections. The application uses existing event/outbox tables; this release adds **no database migration**. `journey:operate` runs every 15 minutes. It holds the existing customer lock before recording observations, deduplicates each customer/hour coverage sample and daily deadline episode, and catches a missed EOD run on the next scan after 18:00. It records observed hours only; it never backdates fabricated samples. A scan failure leaves that customer eligible for the next scan. The health stamp reports completed/failed checks. Reads calculate current deadlines even when the scheduler is behind. ### Performance definitions - Action on-time rate uses `original_due_at`, not the rescheduled date. A reschedule chain is one obligation. Completed/no-answer attempts can count as an action completed; they do not establish customer readiness. Open or late actions remain in the denominator once due. Accepted specialist work is attributed to its specialist. - Today’s purchase coverage is the arithmetic mean of recorded hourly percentages across accessible opportunities. Initial enquiries are shown separately and are not in the purchase denominator. Historical samples are filtered through current customer access. - Qualified Zoom consultations shown in this view require an accepted host, a confirmed purpose and a measured, matched Zoom consultation of at least ten minutes. The displayed count is explicitly limited to open purchases. - Team progress shows recorded Ready transitions and confirmed facts. Stage pace uses completed stage transitions, with sample counts. AI acceptance/rejection is operational review telemetry; it does not replace the independently labelled release evaluation. Historical telemetry is available only to managers with access to all contributing channels. ### Sending controls Customer dispatch requires the existing `JOURNEY_AUTOMATION` control. Staff notifications additionally require `JOURNEY_OPERATIONS_NOTIFICATIONS` and each recipient’s personal `journey.daily_work` Notify subscription. Both ship disabled. There is no shared-group fallback. For customer dispatch, configure a current, active company **Cloud API** flow: - `JOURNEY_REMINDER_FLOW_ID`: agreed consultation reminders in the T−24h and T−2h windows. - `JOURNEY_REENGAGEMENT_FLOW_ID`: no-show/two-missed-attempt follow-up, at most one attempt per Malaysia day and three ledger entries per unanswered episode. - `JOURNEY_REENGAGEMENT_AI_PROFILE`: optional existing AI caller profile. Its calling-hour, block and spending controls still apply. The first flow step must be a validated, approved non-authentication template. Bridge/personal CEO channels and a sender ending in 4886 are refused. A request waiting for a staff reply pauses automated follow-up. The dispatcher admits at most one customer per minute; invalid flow configuration postpones the intent for one hour with a visible reason. Every dispatch reloads current agreement, owner, contact policy and context; archived/converted/closed work is refused. Provider handoff is at most once: an interrupted handoff is held for investigation, not automatically replayed. `Delivered` in the journey outbox means handed to the existing channel engine, not proof of customer delivery; consult the channel's delivery ledger. When automation is enabled, a newly registered, verified portal customer with an existing eligible staff owner receives an initial proposed staff-call task due 24 hours after registration. Historical imports and unassigned customers are not silently activated. A staff DNC command synchronously cancels queued funnel sends, pending email campaign recipients and active WhatsApp flows. Send-time checks cover already reserved WhatsApp messages, campaign email, funnel email/SMS/voice/AI calls and the shared AI-call entry point. Restoring contact does not resurrect cancelled jobs. Existing external/provider-accepted calls cannot be recalled by a database flag. ### Retention `journey:retention` produces a bounded content-free manifest. Execution requires BOTH `JOURNEY_RETENTION_EXECUTION=true` and `--execute=`; source revisions and document eligibility are rechecked transactionally. Execution is disabled in this release and is not scheduled automatically. The executor retires local recording copies/transcripts after 12 months, clears linked journey quotes/values/review text/AI traces, invalidates derived facts, and adds replay-suppression fingerprints. It clears native recording summaries and related review/plan content and makes recording rows unavailable to queued processors. Storage files are handed to the existing durable media-cleanup outbox, so storage failure is retryable. Identity files and consent snapshots become eligible 24 months after the customer's last relevant purchase closed. A current purchase, recent closure, or active initial enquiry holds shared documents. Newer files remain protected. The manifest reports each affected local record before any deletion. Native income-document collections are not currently modelled by this release; new document types must be added to the explicit inventory before enabling their retention. Provider-owned Zoom/voice/badge storage, legacy external file paths, backups, exported reports and external AI-provider retention are outside local deletion. Their channel owners must configure those retention policies before claiming complete end-to-end erasure. Audit decision metadata is preserved; no broad five-year audit purge is enabled here. ## Recovery and release controls - `journey:operate --dry-run`: observe due controls without writes or sends. - `journey:operate`: retry failed local observations safely. - `journey:operate --dispatch`: process configured customer intents, only while automation is enabled. - Disable automation to stop new customer handoffs. Disable staff notifications independently. - Keep general/scheduled AI extraction gated until its separate evaluation passes. - Preview retention again after any source or customer change. Never reuse a stale manifest fingerprint. - No database rollback is needed for this code-only release. Preserve generated event history when reverting code. ## Related [Revenue Journey](readMe.md) · [AI preparation](ai-preparation-contract.md) · [Shared Notify](../notify/readMe.md) · [Shared Media](../media/readMe.md) · [WhatsApp flow](../../manage/messages/whatsapp/flow.md)