SoloPilot

Intent Detect

Automatically reads incoming emails and DMs to spot scheduling intent, extract preferred times, topics, duration, participants, and meeting mode. Generates a one-click booking draft mapped to your availability so you can confirm in seconds—no back-and-forth or copy-paste.

Requirements

Channel Connectors & Unified Message Ingestion

"As an independent professional using SoloPilot, I want my email and DM accounts connected and messages ingested automatically so that scheduling intents can be detected without manual forwarding or copy-paste."

Description

Build OAuth-based connectors for Gmail/Google Workspace, Outlook/Microsoft 365, and generic IMAP, plus webhook-based connectors for major DM platforms (e.g., Slack/Teams). Ingest inbound messages and metadata in near real-time, normalize into a unified schema, thread conversations, deduplicate, and filter out auto-replies and spam. Detect sender identity and map to existing SoloPilot contacts. Preserve original timestamps, language, and time zone indicators. Enforce least-privilege scopes and encrypted token storage. Expose an internal ingestion event for downstream intent detection and extraction workflows, with idempotency and retry policies for robustness. Provide admin UI to connect accounts, view connection status, and pause/resume ingestion per channel.

Acceptance Criteria

OAuth Email Connectors: Google Workspace and Microsoft 365

- Given an admin opens Admin > Integrations, When they click Connect for Google or Microsoft and complete OAuth consent, Then a new connection is listed with provider in {Google, Microsoft}, channel="Email", and status="Connected" within 10 seconds. - Then the granted scopes are read-only for message content and metadata only (no send/delete/modify scopes), and the exact scopes are displayed in UI and recorded for audit. - Then access/refresh tokens and tenant identifiers are stored encrypted at rest using platform KMS; no plaintext tokens appear in logs or exports. - Given consent is revoked or tokens expire, When the 5-minute health check runs, Then the connection transitions to status="Error" with lastError set, and ingestion is suspended until re-authorized. - Given the connection is Connected, When a new email is delivered to the mailbox, Then an ingestion event is emitted within 10 seconds p95 of provider delivery.

Generic IMAP Connector

- Given an admin enters IMAP host, port, TLS setting, username, and app password (or OAuth2), When Test Connection succeeds and the form is saved, Then a new connection is listed with provider="IMAP", channel="Email", status="Connected". - IMAP sessions must use TLS; credentials are stored encrypted at rest and are never logged in plaintext. - The connector operates in read-only mode; no message modifications or deletions are issued. - New message detection uses IDLE (if supported) or polling at ≤30s interval; upon arrival, an ingestion event is emitted within 30 seconds p95. - Duplicate ingestion is prevented using UIDVALIDITY+UID keys across reconnects; the same message is not stored or emitted twice.

DM Webhook Connectors: Slack and Microsoft Teams

- Given an admin installs the SoloPilot app and completes the workspace/team authorization, When the platform verification challenge is received, Then the app responds within 5 seconds and the connection shows status="Connected" with channel in {Slack, Teams}. - Granted scopes are least-privilege for reading direct messages to the user only; no write or admin scopes are requested; tokens and signing secrets are stored encrypted at rest. - Only direct messages (and threaded replies to those DMs) are ingested; messages from channels are excluded unless explicitly enabled in settings. - For each new DM, a normalized message is persisted and an ingestion event is published within 5 seconds p95 of webhook receipt. - Webhook redeliveries are handled idempotently using event_id (Slack) or messageId/activityId (Teams); no duplicate downstream triggers occur.

Near Real-Time Ingestion, Idempotency, and Retry

- Given a new inbound message arrives on any connected channel, When the connector receives it, Then a normalized record is persisted and an ingestion event is published within 5 seconds p95 (10 seconds p99) of provider delivery. - Each ingestion event includes idempotencyKey composed from provider-specific immutable identifiers and channel; processing the same event multiple times results in a single stored message and one effective downstream trigger. - Transient failures in fetch or publish are retried with exponential backoff up to 5 attempts over 15 minutes; permanent failures are dead-lettered with error class and reason. - The system provides at-least-once delivery guarantees for ingestion events; consumers can de-duplicate using idempotencyKey. - End-to-end latency and retry metrics are exported, with alerts when p95 latency exceeds the SLA for 5 consecutive minutes.

Unified Normalization, Threading, Deduplication, and Metadata Preservation

- For every ingested message, the stored record includes unified fields: provider, channel, messageId, threadId, inReplyTo, from, to, cc, bcc (if available), subject (email), bodyText, bodyHtml (if available), attachments metadata (filename, size, mime), receivedAtOriginal, receivedAtUtc, timezoneOffset, languageCode, and redacted rawHeaders. - Threading links replies to existing conversations using thread identifiers (e.g., RFC822 In-Reply-To/References, Slack thread_ts, Teams replyToId); new roots create a new threadId. - Deduplication prevents multiple records for the same logical message using provider identifiers (e.g., Message-ID, IMAP UIDVALIDITY+UID, Slack ts) with content-hash fallback; duplicate inputs do not create additional records or events. - Original provider timestamp, language, and timezone indicators are preserved without transformation in receivedAtOriginal and related fields, alongside normalized UTC. - Messages classified as auto-replies or spam (e.g., Auto-Submitted, X-Auto-Response-Suppress, known OOO patterns, provider spam flags) are tagged ignored and do not emit downstream events; ignoreReason is stored for review. - All records pass schema validation; optional fields are present as null when unknown.

Sender Identity Resolution and Contact Mapping

- For each ingested message, the system attempts to resolve the sender to an existing SoloPilot contact and sets contactId when matched. - Email: case-insensitive exact match on primary email maps to a single contact; multi-match selects the most recently active contact and records ambiguity=true. - Slack/Teams: resolve via platform userId to known email; if email maps to a contact, link; otherwise store platform handle and mark contactId=null. - If no contact is found, the message remains ingestible with contactId=null; no contacts are auto-created by ingestion. - Mapping decision includes confidence level and method (email_exact, platform_userId_email, none) and is auditable in logs.

Admin UI: Connect, Status, and Pause/Resume per Channel

- Admin > Integrations lists all connections with provider, channel, account label, status in {Connected, Paused, Error, Reconnecting}, lastEventAt, lastErrorAt, and action buttons. - Admin can pause ingestion per connection; while paused, no new ingestion events are published, and a Paused badge appears on the connection. - Admin can resume ingestion; upon resume, the connection returns to status="Connected" and processes any queued/provider-retained messages. - Health checks and recent error summaries are visible; hovering status shows the most recent error and timestamp. - All connect, disconnect, pause, resume, and scope changes are captured in audit logs with actor and timestamp.

Intent Classification with Confidence Thresholds

"As a coach, I want SoloPilot to automatically recognize when a message is trying to set or change a session so that I can respond faster without reading every email in detail."

Description

Implement an NLP classifier that labels inbound messages for scheduling-related intents (e.g., request to book, reschedule, cancel, confirm, availability inquiry). Provide per-intent confidence scores, configurable thresholds, and reasons/explanations (top features/snippets) to support operator trust. Support multilingual detection and handle noisy or partial messages. Surface classification outcomes as events that trigger entity extraction and draft generation. Allow admin-level configuration of which intents should auto-draft vs require manual review. Track precision/recall metrics and latency, targeting sub-500ms inference for typical messages.

Acceptance Criteria

Baseline Intent Classification and Confidence Output

Given an inbound message in a supported language that expresses exactly one scheduling-related intent When the message is processed by the intent classifier Then the response includes a primary_intent in {"request_to_book","reschedule","cancel","confirm","availability_inquiry"} And the response includes a confidences map with a key for each supported intent and values in [0.0,1.0] And primary_intent corresponds to the intent with the highest confidence And the response includes language_code (ISO 639-1), classification_id, and processed_at timestamp

Configurable Per-Intent Confidence Thresholds

Given an admin has configured confidence thresholds per intent with values in [0.0,1.0] And the system persists these thresholds When a message is classified Then the decision.outcome is "above_threshold" if primary_confidence >= threshold[primary_intent], otherwise "below_threshold" And the classification event payload includes primary_confidence and threshold_used And if the outcome is "below_threshold" no automatic drafting action is taken and the item is marked for manual review

Admin Policy: Auto-Draft vs Manual Review

Given an admin policy sets auto_draft=true for {"request_to_book","reschedule"} and auto_draft=false for other intents When a classification outcome is "above_threshold" for an intent with auto_draft=true Then a booking_draft.create event is emitted with the message_id and primary_intent And the draft is generated against the owner's availability without user input When a classification outcome is "above_threshold" for an intent with auto_draft=false Then a review_task is created and visible in the Inbox within 2 seconds When a classification outcome is "below_threshold" Then a review_task is created and no draft is generated

Explanations and Evidence Transparency

Given a message is classified When the classification event is produced Then it includes explanations.top_snippets containing 1 to 3 entries And each entry includes text, start_offset, end_offset, and a non-negative score And each text is an exact substring of the original message corresponding to the offsets And the UI highlights these snippets and displays their scores on the review panel

Multilingual and Noisy/Partial Message Handling

Given held-out test sets for English, Spanish, French, German, Portuguese, and Italian with at least 300 messages per intent per language When evaluated offline Then the macro-average F1 across supported intents is >= 0.82 for English and >= 0.80 for each other supported language And per-intent F1 is >= 0.78 for each supported language Given messages containing up to 10% character-level noise (typos, emoji, repeated punctuation) or code-switching between two supported languages When processed Then the classifier returns a valid primary_intent with macro F1 >= 0.75 and sets language_code to the dominant language Given messages with fewer than 5 tokens or ambiguous intent When processed Then the classifier returns primary_intent="unknown" with primary_confidence <= 0.50 and flags ambiguous=true

Event Emission and Downstream Triggers

Given any classification is completed When the event is emitted Then an intent.classified event is published within 50 ms of model completion with payload: message_id, primary_intent, confidences, language_code, threshold_used, decision.outcome, explanations.top_snippets And an entity.extract.requested event is published within 100 ms of the intent.classified event And if the admin policy and thresholds permit auto-drafting for the primary_intent, a booking_draft.create event is published; otherwise only a review_task is created And all events are deduplicated by classification_id and are idempotent

Latency and Metrics Tracking

Given a production-like load of 10 requests/second and messages <= 1500 characters When measured over 10,000 classifications Then p95 end-to-end classification latency (request received to intent.classified event published) is <= 500 ms and p50 <= 200 ms And per-request inference_duration_ms and end_to_end_duration_ms are logged And daily aggregates of precision, recall, and F1 per intent and language are computed and stored for the last 30 days And a dashboard or API exposes per-intent volumes, p50/p95 latency, and precision/recall time series And an alert is sent to the ops channel if any intent’s 7-day rolling precision drops below 0.80 or p95 latency exceeds 500 ms for 15 consecutive minutes

Entity Extraction for Scheduling Parameters

"As a therapist, I want SoloPilot to pull out the when, how long, who, and how we’ll meet from a client’s message so that I don’t have to retype details into a booking."

Description

Extract structured fields from detected-intent messages, including preferred dates and times (with ranges and alternatives), duration, session topic, participants, meeting mode (in-person, video, phone), location or video platform preference, and time zone. Resolve ambiguities (e.g., “next Tuesday afternoon”), recognize recurrence, and parse attachments or calendar proposals (ICS). Support multilingual and locale-aware parsing. Output a normalized payload with confidence per field and rationale snippets, and flag low-confidence fields for user review. Integrate with SoloPilot contact records to map mentioned participants. Log extraction outcomes for analytics and model improvement.

Acceptance Criteria

Resolution of Relative Time Phrases and Ordered Alternatives

Given a detected scheduling-intent message: "Next Tuesday afternoon works; otherwise Wednesday 3–5pm. 45 min" And the user's account timezone is a valid IANA zone (e.g., America/Los_Angeles) and locale is en-US with daypart mapping afternoon = 12:00–17:00 When the extractor processes the message on a reference date Then it resolves "next Tuesday" to the Tuesday after the reference date and maps "afternoon" to a window 12:00–17:00 local And it parses "Wednesday 3–5pm" to a window 15:00–17:00 local And it sets duration = 45 minutes for both candidates And it returns time_preferences as an ordered list where the first candidate corresponds to "Next Tuesday afternoon" and the second to "Wednesday 3–5pm" And each candidate includes ISO 8601 start/end with timezone, source = "text", a rationale snippet quoting the exact phrase, and confidence (>= 0.85 for the first candidate and >= 0.80 for the second) And if multiple locale interpretations exist causing confidence < 0.80, the affected candidate is included with require_review = true

Participant Identification and Contact Mapping

Given a message mentions participants: sender "Jordan <jordan@client.com>", "Alex Chen <alex@acme.com>", and "Priya (my EA)" And SoloPilot contacts contain records for jordan@client.com and alex@acme.com but not for Priya When the extractor processes the message headers and body Then participants are returned as a deduplicated list including Jordan, Alex, and Priya And Jordan and Alex are mapped to their existing contact_id values by email with confidence >= 0.90 And Priya is included with name = "Priya", contact_id = null, confidence < 0.90, and require_review = true And each participant entry includes source (header or text), rationale snippet (quoted mention), and normalized email if present

Meeting Mode, Location, and Platform Extraction

Given a message text: "Prefer Zoom; if not, phone at +1 (415) 555-0199; or meet at 123 Main St, San Francisco" When the extractor processes the message Then meeting_mode_preferences are returned in the order ["video","phone","in_person"] And platform = "Zoom" is extracted with confidence >= 0.90 and a rationale snippet quoting "Zoom" And phone is normalized to E.164 "+14155550199" with confidence >= 0.90 and a rationale snippet quoting the number And location.address = "123 Main St, San Francisco" is extracted (as a single-line normalized string at minimum) with confidence >= 0.85 and a rationale snippet quoting the address

Recurrence Recognition and Normalization

Given a message: "Let's meet every other Wednesday at 10am for 6 weeks starting next week" And the user's timezone is a valid IANA zone (e.g., Europe/London) When the extractor processes the message on a reference date Then it outputs recurrence.rrule = "FREQ=WEEKLY;INTERVAL=2;COUNT=6;BYDAY=WE" And it resolves start_datetime to the Wednesday of the week after the reference date at 10:00 local in ISO 8601 And it includes rationale snippets for "every other Wednesday", "for 6 weeks", and "starting next week" And it assigns confidence >= 0.85 to the recurrence field

ICS Attachment Parsing and Conflict Resolution

Given an email has an attached ICS proposing Wednesday 15:00 UTC and the body text states "Thursday 3pm works best" When the extractor processes both the attachment and the text Then it returns at least two candidate time options labeled with source = "ics" and source = "text" And each candidate includes ISO 8601 datetimes normalized to the appropriate timezone and a rationale snippet citing its source And the top_candidate is set to the "text" option when preference phrases like "works best" are present And a conflict object is included listing the differing proposals And review_required is set to true if the confidence difference between the top two candidates is < 0.10; otherwise false

Multilingual and Locale-Aware Parsing

Given a message in Spanish: "Podemos vernos el lunes 10/11 a las 16h por Google Meet. Zona horaria: CET." And detected language = "es" and sender locale = es-ES When the extractor processes the message Then the date is interpreted using dd/MM (10 November) with time 16:00 and timezone Europe/Madrid (CET) in ISO 8601 And meeting_mode = "video" and platform = "Google Meet" are extracted with confidence >= 0.90 And each extracted field includes language_code = "es" in its rationale metadata And no MM/DD (en-US) heuristics are applied during parsing

Normalized Payload, Confidence, Rationale, Review Flags, and Analytics Logging

Given a scheduling-intent message is processed When entity extraction completes Then the system returns a normalized payload containing applicable fields: time_preferences or time_windows, duration, topic (if present), participants, meeting_mode, platform or location, timezone, and recurrence, each with ISO-normalized values And every returned field includes: confidence in [0,1], source (e.g., text, ics), and a rationale snippet quoting the evidence span And any field with confidence below the configured threshold (default 0.80) is included with require_review = true and listed in review_fields And the system emits a telemetry event "intent_extract_v1" with request_id, user_id (pseudonymous), model_version, language, fields_extracted count, average_confidence, duration_ms, and success flag And the telemetry event contains no full message body and limits rationale snippets to a maximum of 140 characters

Availability Mapping & Booking Draft Generation

"As a freelancer, I want SoloPilot to turn the parsed details into a ready-to-confirm booking mapped to my real availability so that I can schedule in seconds."

Description

Map extracted preferences to the user’s calendars and SoloPilot scheduling rules (working hours, buffers, service durations, blackout dates, locations, video integrations) to compute the best-fitting slots. Generate a booking draft that includes proposed time(s), participants, location/mode, and service type, with conflicts and constraints respected across connected calendars. Offer ranked slot suggestions, soft-hold options, and automatic time zone alignment. Pre-populate session notes and invoice line items per service configuration. Persist drafts with audit trail and expose them in the SoloPilot dashboard and via notifications for quick confirmation.

Acceptance Criteria

Rule-Compliant Availability Mapping

Given a user has defined working hours, minimum/maximum notice, service durations, buffers, blackout dates, and connected calendars with busy/free transparency And an intent has extracted a service type, preferred windows, duration, participants, and location/mode preferences When the system computes candidate slots Then every returned slot falls within working hours, observes pre/post buffers, meets min/max notice, avoids blackout dates, and matches the service duration And no returned slot overlaps a busy event on any connected calendar And location/mode constraints (e.g., in-person day/location availability) are respected And if no valid slots exist, the system returns a "No slots available" result with a list of violated rule(s) per rejected window

Comprehensive Booking Draft Generation

Given candidate slots have been computed for an intent When a booking draft is generated Then the draft includes: ranked proposed times (default 3, configurable 1–5), participants, service type, duration, requester and host time zones, location/mode, and per-slot soft-hold flags And session notes are pre-populated from the service template with extracted topic/agenda fields inserted And invoice line item(s) are pre-populated from service configuration with correct rate, quantity/duration, taxes/discounts, and computed total And no external invitations or invoices are sent until the draft is explicitly confirmed And all draft fields are editable prior to confirmation

Ranked Suggestions and Soft-Hold Lifecycle

Given slot ranking is required When ranking is performed Then slots are ordered by match to stated preferences (date/time window, duration), earliest acceptable time, and rule fit; ties are broken by least calendar fragmentation And each slot displays its rank position When the user enables soft-hold on proposed slots Then the system creates busy holds on the primary calendar for each selected slot that last 24 hours by default (configurable) And holds prevent double-booking and auto-expire on timeout or manual cancel And on confirmation, the chosen hold converts to a booked event and all other holds are released And while on hold, no external invites are sent

Automatic Time Zone Alignment and DST Safety

Given the requester’s time zone can be derived from headers, message content, or stored profile When presenting proposed times Then times are shown in the requester’s time zone and the host’s local time zone, stored as IANA IDs And DST transitions are correctly applied to start/end times And if the requester’s time zone cannot be determined, the system defaults to the host’s time zone and flags "Time zone unconfirmed" for user review When the draft is confirmed Then the booked event reflects correct times for all participants’ time zones in calendar invites and notifications

Cross-Calendar Conflict Detection and Error Handling

Given multiple connected calendars (e.g., personal, work, resources) with event transparency When computing availability Then events marked Busy on any connected calendar block time; events marked Free do not And all-day Out of Office blocks the entire day And Tentative events block if the user’s preference is set to block tentative; Declined events do not block And if any calendar API is unavailable or times out, the system marks availability as Unknown for affected windows, suppresses proposing slots in those windows, and surfaces a retriable sync error in the draft

Service, Location/Mode, and Video Integration Mapping

Given the selected service defines duration, allowed locations/modes (in-person addresses, phone, video), travel/room constraints, and a default video provider And the intent includes a preferred mode/location when stated When generating slots and the draft Then only slots compatible with the service duration and location/mode constraints are proposed (e.g., travel buffers for in-person, room availability) And the video provider is selected per user default or explicit preference; the meeting link is created on confirmation (not during soft-hold) and populated into the draft And for in-person, the address is included; for phone, call-in instructions from the template are included

Draft Persistence, Audit Trail, Dashboard Visibility, and Notifications

Given a booking draft is created or updated When it is saved Then it is persisted with a unique ID, created/updated timestamps, source message ID(s), extracted fields, applied scheduling rule version(s), ranking rationale, and actor identity And all changes are recorded in an immutable audit log with before/after values And the draft appears in the SoloPilot dashboard Drafts list within 5 seconds and is filterable/searchable by status, service, requester, and date range And notifications (in-app and email) are sent with a deep link to the draft And only one confirmation can succeed per draft; concurrent confirmations are rejected with a clear message And drafts auto-expire and archive after 90 days of inactivity

One-Click Confirm & Smart Reply Composer

"As a consultant, I want to confirm a suggested time and send a polished reply with one click so that I avoid back-and-forth and keep my workflow moving."

Description

Provide a compact UI surface in the SoloPilot inbox and notifications to review extracted details and confirm with one click. Automatically generate a context-aware reply for the original channel (email or DM) with confirmation or proposed times, including an ICS invite or booking link as appropriate. Support editable templates, variable insertion, and tone presets. On confirmation, create the calendar event, send confirmations, update SoloPilot records, and trigger follow-on automations (reminders, notes template, invoice draft). Log all outbound communications and respect channel rate limits and threading.

Acceptance Criteria

One-Click Confirmation from Inbox UI

Given an inbound message with detected scheduling intent and at least one viable time mapped to the user’s availability When the user opens the SoloPilot inbox item or push notification surface and clicks Confirm Then the booking is confirmed without additional forms, required fields (time, duration, participants, mode) are auto-populated, and a success state is shown And the Confirm action is disabled until all required fields are present or resolved And the compact UI displays extracted fields (topic, time, duration, participants, mode) and highlights conflicts before confirmation And p95 time from Confirm click to visible success state is ≤ 5 seconds

Context-Aware Reply with ICS or Booking Link

Given the original channel is email and the user confirms a specific time When the confirmation is sent Then a reply is drafted and sent in the same email thread with correct subject threading headers and includes an ICS invite with accurate start/end time, timezone, attendees, and location/mode And the email body summarizes confirmed details and uses the selected template and tone Given the original channel is a DM that does not support ICS attachments When the confirmation is sent Then a message is posted in the original thread with the confirmed details and an auto-generated booking link or calendar file fallback, formatted per channel conventions

Alternative Time Proposals on Availability Conflict

Given the extracted request time is unavailable or ambiguous When the user clicks Propose Times Then the system suggests 3 alternative slots within the user’s configured working hours and meeting preferences, respecting both parties’ time zones and avoiding conflicts And the reply is composed in the original channel thread listing the proposed slots with one-click selection or a booking link pre-filtered to those slots And if no slots are available in the next 10 business days, the reply explains unavailability and offers the booking link with broader availability

Template Editing, Variable Insertion, and Tone Presets

Given templates with variables are configured When the user selects a template and tone preset in the composer Then the preview renders with resolved variables (e.g., client.first_name, meeting.time, meeting.mode, booking.link) in the correct locale and timezone And unresolved variables are surfaced with inline validation and block send until resolved or removed And the user can edit the message before send, and the final sent content matches the edited preview And the selected tone preset adjusts phrasing per style guide without altering factual details (time, location, links)

Post-Confirmation Event Creation and Automations

Given a confirmation is submitted When back-end processing completes Then a calendar event is created in the connected calendar with correct title, start/end time, timezone, attendees, and conferencing details/mode And attendee confirmation/invite is sent, SoloPilot session record is created/updated, reminders are scheduled, a notes template is attached to the session, and an invoice draft is created with duration and mapped rate And duplicate submissions within 60 seconds are idempotent (exactly one event/invite and one invoice draft) And p95 time from confirmation to event creation is ≤ 10 seconds; downstream artifacts (reminders, notes template, invoice draft) are available within 30 seconds

Channel Threading and Rate Limit Compliance

Given provider-specific threading and rate limits When messages are sent by the composer Then email replies include correct In-Reply-To and References headers; DM replies post in the same thread/conversation And the system enforces provider rate limits with queued sends and exponential backoff; no more than the configured per-minute/hour caps are exceeded And when a rate limit is hit, the user is notified in-app within 5 seconds and the message status shows Pending with next retry time

Outbound Communication Logging and Audit Trail

Given any confirmation or proposal is sent When the outbound communication is dispatched Then an immutable log entry is created capturing timestamp, channel, recipients, subject/snippet, thread/message ID, ICS/link status, and delivery outcome And the log is visible on the session timeline and searchable by recipient, date, and thread ID And each confirmation action results in exactly one logged outbound message and one calendar invite log (or a single message with link for non-ICS channels)

Human Review, Corrections, and Personalization Loop

"As a solo operator, I want to quickly fix any misread details and have SoloPilot learn my preferences so that future drafts are accurate by default."

Description

Enable users to review and correct classifications and extracted fields inline, with changes instantly updating the booking draft. Capture corrections and outcomes as feedback signals to personalize future intent detection and extraction per user, service type, and client. Provide opt-in controls, anonymization, and versioned model configurations. Offer quick actions to teach preferred slots, default durations, and phrasing. Include an evaluation dashboard showing accuracy over time and suggested automations to reduce manual steps.

Acceptance Criteria

Inline Correction Updates Draft in Real Time

Given a detected intent message is open in the review panel When the user edits any extracted field (date/time, duration, participants, meeting mode, topic) Then the booking draft preview updates to reflect the change within 300 ms without a page reload and a single debounced PATCH request (<=300 ms) succeeds with 2xx Given the user triggers Undo on a recent change When Undo is clicked or Cmd/Ctrl+Z is pressed Then the field value reverts to the previous value and the draft preview matches the reverted state Given a network error occurs while saving a change When the PATCH request fails Then an inline error message appears within 1 s, the change is not persisted, and a Retry action is available

Corrections Captured as Feedback Signals for Personalization

Given the user confirms a booking after making corrections When the draft is submitted Then a feedback record is stored with before/after values, field types, message ID, user ID, service type, client ID, and timestamp Given feedback storage is successful When the record is written Then it is retrievable in audit logs within 5 minutes and linked to the draft and message Given repeated similar corrections (>=10 within 14 days) for the same field and service type When the nightly personalization job runs Then a new personalized model/version is queued for training and its pending status is visible in the dashboard within 24 hours Given a correction teaches a preference When the next similar message arrives Then the extracted suggestion reflects the learned preference with a visible confidence score; if confidence < 0.7 the field is highlighted for review

Opt-In Controls, Consent, and Anonymization Enforcement

Given a new user opens Intent Detect settings for the first time When the settings page loads Then personalization/data-sharing is OFF by default with an explicit opt-in toggle and a link to the privacy policy and terms Given a user opts in to personalization When the toggle is turned ON and consent is confirmed Then a consent record is created with user ID, timestamp, policy version, and scope, and appears in the audit log Given anonymization is enabled When storing feedback records Then PII (names, emails, phone numbers) is tokenized and raw message bodies are not stored; a sampled record shows token placeholders instead of PII Given a user revokes consent When the toggle is turned OFF Then new data collection stops immediately, prior records are flagged do-not-train, excluded from subsequent training runs, and this is reflected in the dashboard within 15 minutes

Quick Teach Actions for Preferred Slots, Default Durations, and Phrasing

Given the review panel shows a detected meeting request When the user clicks "Teach preferred slots" Then a selector shows top recurring availability windows and saving creates a rule visible in Settings > Preferences Given a user sets a default duration for a service type When "Teach default duration" is saved as 90 minutes for Service X Then future drafts for Service X default to 90 minutes while remaining editable Given a user defines a confirmation phrasing template When a booking reply is generated Then the reply uses the saved template with correct variable substitution (client name, date, time, mode) and no unresolved placeholders Given a taught slot conflicts with real-time availability When generating a draft Then availability is honored, a non-blocking notice explains the conflict, and the next-best slot is proposed

Evaluation Dashboard: Accuracy Over Time and Suggested Automations

Given the user opens the evaluation dashboard When a date range and filters (user, service, client) are applied Then precision, recall, and F1 per field and overall intent detection accuracy are displayed with counts of evaluated messages Given >=50 evaluated messages exist in the selected period When metrics are computed Then 95% confidence intervals are shown and trend deltas vs. prior period are displayed Given repeated manual edits match a pattern (>=3 occurrences in 7 days) When suggestions are generated (daily) Then suggested automations list includes the pattern with an estimated time saved, and a one-click enable option that creates a disabled-by-default rule for review Given the user clicks on a metric When drilling down Then anonymized samples with predicted vs corrected values and confidence scores are displayed

Versioned Model Configurations and Rollback Controls

Given a new personalized model version is deployed When training completes Then the active model version (e.g., v3) and changelog are visible in settings, and inference requests include the version ID in logs Given accuracy drops by >=5 percentage points week-over-week for any key field When the monitoring job runs nightly Then the system flags degradation, automatically rolls back to the previous stable version, and notifies the user within 1 hour Given a user selects a model option When choosing Global, Personalized, or a specific version in settings Then subsequent extractions use the selected option and the choice persists across sessions Given an audit export is requested When the user clicks Export Configuration Then a JSON file is downloaded including model version, enabled rules, feature flags, training dataset references (hashed/IDs), and current consent state

Privacy, Security, and Compliance Controls

"As a professional handling client information, I want strong privacy controls and transparent handling of my communications so that I can trust SoloPilot with sensitive data."

Description

Implement end-to-end encryption in transit and at rest for message content and tokens, enforce least-privilege OAuth scopes, and isolate tenant data. Provide data retention controls, redact sensitive content in logs, and support regional data residency where available. Include audit logging for access, actions, and model inferences tied to user accounts. Offer consent notices and opt-out for automated processing to meet privacy expectations, and align with applicable regulations (e.g., GDPR). Perform threat modeling, rate limiting, abuse detection, and backup/restore procedures for ingestion pipelines.

Acceptance Criteria

Encryption and Key Management for Intent Detect Pipelines

Given API endpoints for ingesting emails and DMs, When a TLS handshake occurs, Then TLS 1.2+ with modern ciphers is enforced and weak cipher suites are disabled Given service-to-service traffic, When internal calls are made, Then mutual TLS is required with certificate pinning Given message content and tokens stored at rest, When data is persisted, Then AES-256 encryption at rest via managed KMS keys is applied Given KMS-managed keys, When rotation policy is evaluated, Then keys rotate at least every 90 days and rotation events are logged Given an operator or process, When attempting to access plaintext tokens or message content, Then access is denied and secrets remain unreadable without KMS authorization

Access Control: Least-Privilege OAuth and Tenant Isolation

Given a user connects an email or DM provider, When the consent screen is displayed, Then only the minimum read scopes required for intent detection are requested and clearly described Given an issued access token, When calling any provider API beyond granted scopes, Then the call fails with an insufficient scope error Given multi-tenant data stores, When querying with a tenant-scoped principal, Then results only include that tenant’s data due to enforced row-level and object isolation Given cross-tenant access attempts, When a user from Tenant A requests Tenant B resources by ID, Then a 403 or 404 is returned and an audit event is recorded Given infrastructure credentials, When IAM policies are reviewed, Then permissions follow least privilege and are restricted to tenant and environment boundaries

Data Retention, Deletion, and Backup/Restore

Given a tenant retention setting, When set to N days, Then messages, derived metadata, and inferences older than N days are purged within 24 hours Given a user-initiated delete request, When deletion is confirmed, Then data is hard-deleted from primary stores within 24 hours and excluded from all future processing Given deleted data, When backup lifecycle runs, Then the same data is irrecoverably removed from backups within 30 days according to retention policy Given the ingestion pipeline, When a disaster recovery drill is executed, Then data is restorable to the last successful backup with RPO less than or equal to 24 hours and service RTO less than or equal to 4 hours Given restoration completes, When validation runs, Then message counts, indices, and encryption states match pre-incident baselines

Observability: Redaction, Audit Logging, and Inference Traceability

Given application and access logs, When processing messages or tokens, Then tokens, message bodies, and PII are redacted or hashed before logging Given seeded test secrets and PII, When automated log scans run, Then no raw secrets or full PII values are present in any logs Given user or system actions on message data, When actions occur, Then immutable audit events capture actor, tenant, action, resource, timestamp, IP, and outcome Given a model inference, When logged, Then the audit record includes model and version, input reference (hashed), output summary, and a correlation ID to the source message and actor Given audit log storage, When tamper checks run, Then append-only or WORM guarantees and hash chains validate integrity for at least one year

Regional Data Residency Enforcement

Given a tenant selects an EU or US region, When new data is ingested, Then storage and processing occur only in the selected region Given monitoring of data egress, When cross-region transfer is attempted for tenant data, Then the transfer is blocked and an alert is generated Given region-specific resources, When inspecting infrastructure, Then databases, object stores, and log sinks are provisioned in-region with cross-region replication disabled Given regional unavailability, When failover is considered, Then no cross-region failover occurs without explicit tenant approval and a documented exception

Consent, Opt-Out, and Regulatory Alignment

Given Intent Detect is enabled, When first processing a connected inbox or DM, Then a clear consent notice is displayed and explicit opt-in is recorded with timestamp and actor Given a user opts out, When opt-out is saved, Then automated processing stops within five minutes and no further messages are processed Given opt-out, When reviewing history, Then previously processed data remains accessible per retention policy but is not reprocessed Given a data subject access request, When initiated by the tenant admin, Then an export of processed messages and inferences is available within seven days Given a delete request under GDPR, When confirmed, Then the subject’s data is erased across primary systems within 30 days and queued for backup purge

Threat Modeling, Rate Limiting, and Abuse Detection

Given the Intent Detect feature, When conducting threat modeling, Then STRIDE or LINDDUN analysis is documented with critical and high risks mitigated or explicitly accepted with sign-off Given public-facing ingestion endpoints, When traffic exceeds defined limits, Then 429 responses are returned per IP and per tenant with burst and sustained thresholds enforced Given anomalous patterns such as scripted connects, scraping, or spam waves, When detectors trigger, Then offending principals are throttled or blocked and the tenant admin is notified Given abuse safeguards, When an allowlist is configured for false positives, Then allowlisted principals bypass blocks while remaining rate-limited per policy Given abuse events, When reviewed, Then audit entries include detection reason, thresholds breached, action taken, and reviewer notes

Inline Slots

Inserts live, clickable time options directly into your reply, adjusted to the recipient’s timezone and your real-time availability. Clients pick a slot from the message itself to instantly reserve it, cutting friction and preventing double-booking.

Requirements

Live Availability Sync & Conflict Prevention

"As a solo practitioner, I want Inline Slots to reflect my real-time availability and prevent double-booking so that clients can book confidently without scheduling conflicts."

Description

Implement real-time, two-way availability sync that aggregates SoloPilot calendars and connected external calendars (Google, Outlook, iCloud) to surface only bookable times. Enforce service durations, working hours, buffers, minimum lead time, and max daily capacity. When a recipient clicks a slot, create an atomic, short-lived hold to prevent race conditions and double-booking; release the hold automatically on timeout or upon decline. Respect event privacy and busy/free visibility. Provide graceful fallbacks when availability changes between send and click, guiding recipients to the next best time rather than erroring. All bookings created through Inline Slots must update calendars instantly and trigger SoloPilot’s downstream automations (notes templates, invoicing) without manual intervention.

Acceptance Criteria

Real-Time Aggregated Availability Surfaces Only Bookable Slots

Given a user has SoloPilot, Google, Outlook, and iCloud calendars connected with at least one busy event on each When Inline Slots are generated Then only times not overlapped by any busy event are shown Given a private event exists on an external calendar When calculating availability Then the time is treated as busy and event details are not exposed in API/UI payloads Given the user disconnects an external calendar When refreshing availability Then slots are recalculated within 5 seconds and reflect only remaining calendars Given the user creates a new busy event on any connected calendar When availability is refreshed or the page is reloaded Then the new busy time is excluded within 5 seconds

Timezone-Aware Inline Slots Rendering

Given the recipient's timezone is detectable from their browser or email client headers When Inline Slots are rendered Then slot times display in the recipient's timezone and include the timezone abbreviation Given the recipient's timezone cannot be determined When Inline Slots are rendered Then slots default to the sender's timezone and include a visible timezone label Given daylight savings transitions When slots span the transition date Then displayed times and durations are correct in the recipient's timezone Given the sender changes their working timezone When regenerating Inline Slots Then all slot times are recalculated accordingly

Service Rules Enforcement (Duration, Working Hours, Buffers, Lead Time, Capacity)

Given a service duration of 50 minutes and a 10-minute buffer is configured When availability is calculated Then only start times that allow duration plus buffer to fit within working hours are shown Given a minimum lead time of 24 hours When a recipient views Inline Slots Then times earlier than now plus 24 hours are not shown Given a max daily capacity of 5 sessions for a service When 5 bookings exist for the same day Then no further slots are shown for that day for that service Given overlapping services with different buffers When availability is calculated Then buffers are applied per service and prevent overlaps

Atomic Hold on Slot Click with Auto-Release

Given two recipients click the same slot within 2 seconds When the first hold is created Then the second request receives a temporarily held response and is guided to alternate times Given a hold TTL of 90 seconds When a recipient clicks a slot Then the slot is held exclusively for 90 seconds unless confirmed or declined Given a recipient abandons the flow When the hold TTL expires Then the hold is released and the slot returns to availability within 2 seconds Given the recipient declines or navigates away explicitly When the hold is released Then any provisional calendar entries are removed

Graceful Fallback for Changed Availability

Given a slot was visible at send time but is no longer available at click time When the recipient clicks the slot Then the UI shows a non-blocking message and offers the next three closest times Given no alternative slots exist that day When fallback is shown Then the UI offers the next available day with at least one slot Given alternatives are accepted When the recipient selects a new slot Then booking proceeds without requiring the sender to resend Inline Slots

Instant Booking Propagation and Automations Trigger

Given a slot is confirmed When booking is completed Then a SoloPilot calendar event is created and all linked external calendars are updated within 5 seconds Given booking creation When the event is saved Then SoloPilot downstream automations fire: the notes template is attached to the session and an invoice draft is created with the correct rate and time Given an external calendar write failure When booking is completed Then the SoloPilot event and automations still complete, and the system retries external sync up to 3 times and notifies the user

Privacy and Busy/Free Compliance

Given external calendars have private events When availability is computed Then only busy/free status is fetched and stored; event titles, attendees, and descriptions are neither logged nor exposed to recipients Given API logs and audit trails When inspecting records for availability computations Then no private event metadata beyond start/end and busy state is present Given data processing agreements When the user requests a GDPR export Then availability-derived data excludes third-party event details

Timezone Detection & Locale Rendering

"As a recipient in a different region, I want the proposed times shown in my local timezone so that I don’t need to convert or risk choosing the wrong slot."

Description

Detect and render slot times in the recipient’s timezone automatically using reliable signals (recipient profile, prior bookings, message headers) while allowing manual override. Format times and dates per locale (12/24-hour, weekday names, DST rules) and clearly indicate the timezone displayed. Support multi-recipient messages by defaulting to the first recipient and including a lightweight selector on the confirmation page for others. Handle daylight saving transitions and edge cases by suppressing ambiguous or non-existent times. Cache timezone context per contact in SoloPilot to keep future communications consistent.

Acceptance Criteria

Primary Timezone Detection from Recipient Signals

Given a recipient has a profile timezone set in SoloPilot When the user composes an Inline Slots message Then all inserted slot times render in the recipient’s profile timezone And the timezone indicator displays the IANA ID and current UTC offset Given no profile timezone exists but the recipient has a prior confirmed booking within the last 12 months When composing Inline Slots Then the booking’s timezone is used for rendering Given neither profile nor booking timezone exists but message headers contain a parsable timezone or offset When composing Inline Slots Then the header-derived timezone is used And the source of detection (Profile, Booking, Header, Fallback) is logged for observability Given multiple signals conflict When determining timezone Then apply precedence: Profile > Recent Booking > Message Headers > Workspace Default Given no signals are available When composing Inline Slots Then the workspace default timezone is used

Locale-Aware Rendering and Clear Timezone Indicator

Given a recipient locale is known (e.g., en-US, en-GB, fr-FR) When slots are rendered Then time format follows CLDR rules for that locale (12/24-hour, date order) And weekday names render in the locale language And DST rules are applied for the timezone at the slot’s instant And a visible timezone indicator appears adjacent to the slots Given the recipient locale is unknown When slots are rendered Then default to a 24-hour ISO-like format with weekday (e.g., 2025-10-07 Tue 15:30) And include the IANA timezone and current UTC offset in the indicator Given the sender and recipient share the same timezone When rendering slots Then still display the timezone indicator to avoid ambiguity

Manual Timezone Override in Composer

Given the composer shows a timezone selector defaulted to the detected timezone When the user selects a different timezone before sending Then all inline slot times update immediately to the selected timezone And the selected timezone persists with the draft Given the user checks "Set for contact" When the message is sent Then the contact’s cached timezone updates to the selected timezone Given the user does not check "Set for contact" When the message is sent Then the override applies only to that message and does not update the cache Given a manual override is applied When availability is recalculated Then availability constraints and double-booking protection remain unchanged

Multi-Recipient Defaulting and Confirmation Page Selector

Given a message is addressed to multiple recipients When composing Inline Slots Then default the rendering timezone to the first To: recipient with a contact record And display which recipient’s timezone is being used next to the slots Given any recipient clicks a slot and lands on the confirmation page When multiple recipients were on the original message Then show a lightweight selector to choose the intended attendee And display their timezone beside their name And changing the selected attendee updates displayed times to that attendee’s timezone only And the booked slot and calendar event details remain unchanged; only the display timezone updates Given the selected attendee has no cached timezone When confirming the booking Then allow manual timezone selection and cache it upon successful booking

DST Transitions and Ambiguous/Non-Existent Time Suppression

Given a recipient timezone has a spring-forward transition creating non-existent local times When generating slots for that period Then suppress any non-existent local times from the options Given a recipient timezone has a fall-back transition creating ambiguous local times When generating slots for that period Then suppress ambiguous times from the options And ensure adjacent valid times render with the correct offset after the transition Given a day affected by DST When rendering the slots list Then show an unobtrusive note if the number of visible slots is reduced or increased due to DST Given automated tests run When validating timezone behavior Then include cases for America/New_York, Europe/Berlin, and Asia/Amman for the next 5 years

Per-Contact Timezone Caching and Refresh Logic

Given a timezone is detected or manually set for a contact When the message is sent or a booking is confirmed Then store the contact’s timezone as an IANA ID and a last-validated timestamp Given a cached timezone exists and is less than 6 months old When composing Inline Slots for that contact Then reuse the cached timezone without re-detection Given a new confirmed booking occurs in a different timezone for the same contact When composing the next message to that contact Then prompt the user to update the cached timezone; if accepted, update the cache and use the new timezone Given contact data governance rules When a contact is deleted Then remove the associated timezone cache entries And expose API endpoints to read/write the contact timezone with audit trail entries on change

Inline Slot Generation & One‑Click Insertion

"As a busy consultant replying to a client, I want to drop in live time options with one click so that I can schedule without leaving my email."

Description

Enable users to insert live, clickable time options directly into replies from SoloPilot’s composer and popular email clients (Gmail and Outlook web/desktop) via extension or copy-to-clipboard snippet. Allow selection of service type, duration, location (e.g., video link, phone, in-person), number of options, and earliest/latest windows. Render slots as accessible, tappable chips that resolve through secure magic links, with graceful plaintext fallbacks for clients that strip HTML. Ensure snippets remain valid after send by resolving availability at click time and updating styling to reflect expired or taken slots. Provide a quick preview before insertion and remember last-used settings per user.

Acceptance Criteria

Cross-Platform One‑Click Insertion From Composer

Given the user is composing in SoloPilot, When they click "Inline Slots", Then the slot picker opens within 300 ms. Given Gmail Web, Outlook Web, or Outlook Desktop with the SoloPilot extension, When the user invokes "Insert Inline Slots", Then the slots are inserted at the cursor position, preserve surrounding formatting, and the message remains editable. Given no extension is available, When the user uses "Copy snippet" and pastes into the email, Then the pasted content renders functional clickable chips in HTML clients and includes plaintext fallback markers. Given insertion completes, Then the block contains service name, duration, location label, recipient timezone label, and the configured number of options. Given the user presses Ctrl/Cmd+Z, Then the entire inserted block is undone in a single step.

Slot Generation With Configurable Parameters

Given the user selects service, duration, location, number of options (1–10), earliest and latest windows, When Generate is clicked, Then the generated slots fall within the window, match the duration, respect busy events across all connected calendars, and equal the requested count unless fewer are available. Given fewer contiguous slots are available than requested, Then the system returns all available matches and labels the preview accordingly. Given a location is selected (video, phone, in-person), Then the slot carries the correct meeting link or instructions into the booking flow. Given the earliest window is later than the latest window or no availability exists, Then the UI displays "No available times" and disables Insert.

Recipient Timezone Auto-Adjustment

Given a known recipient, When the picker opens, Then the recipient timezone is auto-detected and displayed; if detection fails, it defaults to the sender's timezone with a visible override. Given the preview, Then times display in the recipient's timezone with an explicit abbreviation and UTC offset. Given multiple recipients with differing timezones, Then a note indicates which timezone is applied and allows manual override before insertion. Given a DST boundary within the selected window, Then times reflect the correct offsets.

Accessible Chips and Plaintext Fallback

Given an HTML-capable client, Then each slot renders as a button with role="button", an accessible name "Book [Day] [Time] [TZ]", is reachable via keyboard, shows a visible focus indicator, has minimum 44x44 px tap area, and meets WCAG 2.1 AA contrast (>= 4.5:1). Given HTML is stripped, Then the email shows a plaintext list of options in the format "1) Day, Date, Start–End (TZ) – [Book link]" plus a fallback booking link. Given a screen reader, When the user navigates to a chip, Then it announces status (Available/Taken/Expired) and activation instructions.

Magic Link Resolution and State Styling

Given a recipient clicks a slot, When the server validates availability, Then, if available, booking proceeds with service, duration, location, and recipient email pre-filled and confirmation completes within 2 steps. Given a clicked slot is taken or expired, Then the landing shows "No longer available" and offers at least three nearest alternative times consistent with the original settings. Given an email client that loads remote content, Then chips fetch current state and visually show Taken/Expired without breaking layout; if remote content is blocked, the click-through page reflects state accurately. Given magic links, Then tokens are signed, single-use, scoped to user/service/slot, and expire no later than 30 days after send or immediately after slot end, whichever comes first.

Preview and Sticky Settings

Given the picker is configured, When Preview is opened, Then it shows exactly how chips and plaintext fallback will render, including timezone labels, and Insert is disabled until preview is generated. Given Insert is clicked, Then the inserted content matches the preview byte-for-byte. Given the user returns to Inline Slots later, Then the last-used settings (service, duration, location, options count, earliest/latest windows, timezone preference) are pre-populated and synced to the user's account so they persist across devices within 5 minutes.

Double-Booking Prevention and Concurrency

Given two recipients attempt to book the same slot at roughly the same time, Then only the first confirmed booking succeeds; subsequent attempts surface "No longer available" with alternatives; no duplicate calendar entries are created. Given a calendar event is added to the user's calendar between email send and slot click, Then the system marks the slot unavailable at click time and prevents booking. Given booking is confirmed, Then the event is created on the correct calendar with service, duration, location, and attendee details, and the slot chips subsequently display Taken in clients that load remote content.

Instant Booking & Confirmation Flow

"As a client, I want my chosen time to be immediately confirmed with a calendar invite so that I know the meeting is set without extra back-and-forth."

Description

On slot click, route the recipient to a minimal confirmation step or auto-confirm based on sender’s settings. Validate availability, apply buffers, and finalize the reservation in under two seconds. Optionally collect lightweight intake questions and display price or payment instructions when applicable. Send confirmation emails to both parties, generate calendar invites (ICS) and conferencing links, and include reschedule/cancel links respecting policy windows. Automatically create the session record in SoloPilot, attach the relevant notes template, and prime invoicing automation as configured.

Acceptance Criteria

Auto-Confirm on Slot Click

Given the recipient clicks a live inline slot and the sender’s booking mode is Auto-confirm When the click is received Then the system validates the slot against real-time availability and applies configured pre/post buffers And the reservation is finalized within 2 seconds end-to-end (95th percentile) And the recipient is routed to a success page showing start/end time in the recipient’s timezone, service name, and conferencing link And the page displays price or payment instructions when configured And the slot is immediately removed from availability to prevent any subsequent booking of the same time

Minimal Confirmation With Intake

Given the recipient clicks a live inline slot and the sender’s booking mode requires a minimal confirmation step with optional intake questions When the confirmation page loads Then the page is prefilled with the selected time in the recipient’s timezone and required/optional intake fields per service configuration (max 5 fields) And field validations (required, format) are enforced client- and server-side When the recipient submits the form Then the system re-validates availability and buffers and finalizes the reservation within 2 seconds end-to-end (95th percentile) And a confirmation screen shows time, conferencing link, and price/payment instructions when applicable

Availability Validation and Alternatives

Given a slot click is received When the selected slot is no longer available or violates buffer/availability rules Then the booking is blocked and no reservation is created And the recipient is shown a clear message that the slot is no longer available And at least 3 next available alternative slots are displayed in the recipient’s timezone based on current real-time availability And the failure response is returned within 2 seconds end-to-end (95th percentile) And no confirmation emails or calendar invites are sent

Concurrent Clicks and Double-Booking Prevention

Given two or more recipients click the same slot within a short interval When the system processes these requests Then at most one reservation is created for that slot And all subsequent requests for the same slot receive an "unavailable" message with alternative slots And no double-booked events appear in any connected calendars And the winner’s reservation is finalized within 2 seconds end-to-end (95th percentile)

Confirmation Emails, ICS, and Conferencing

Given a reservation is finalized When notifications are dispatched Then both parties receive confirmation emails within 60 seconds And each email includes an ICS attachment with correct start/end time, timezone, organizer, attendee, UID, and conferencing link in the Location or conferencing field And the conferencing link is generated per service settings and is accessible by both parties And emails include reschedule and cancel links that encode the booking and respect policy windows

Session Record, Notes Template, and Invoicing Automation

Given a reservation is finalized When post-booking actions run Then a SoloPilot session record is created with service, client, start/end time, timezone, and pricing (when configured) And the relevant notes template for the service is attached to the session And invoicing automation is primed per configuration (e.g., draft invoice created or post-session invoice rule armed) with pre-populated line items and due-date rules And the recipient’s confirmation screen shows price or payment instructions as configured

Reschedule/Cancel Links Respect Policy Windows

Given a booking exists with reschedule/cancel policies (e.g., 24-hour cutoff) When the recipient clicks reschedule or cancel from the email or confirmation page Then within the allowed window, the action proceeds: reschedule shows current availability (recipient’s timezone), and upon confirmation updates the event, sends updated emails/ICS, and regenerates conferencing details if required And outside the allowed window, the action is blocked with a clear policy message and no changes are applied And any successful change updates availability in real time and preserves invoice/session linkages

Templates, Rules & Personalization Controls

"As a therapist managing different session types, I want templates that auto-apply the right durations and buffers so that I don’t have to reconfigure slots for every message."

Description

Provide a configuration UI to define reusable Inline Slot templates with defaults for service, duration, location, buffers, lead/cutoff times, and number of options. Support personalization tokens (e.g., recipient first name, service name) and conditional rules (new vs. existing client, paid vs. free consult) to tailor availability windows and messaging. Allow per-channel behavior (email vs. chat), limits on how often the same contact is offered slots, and a fallback to a booking page when no suitable slots exist. Expose team-wide presets for consistency while allowing user-level overrides.

Acceptance Criteria

Create and Apply Inline Slot Template Defaults

- Given I am in Inline Slots settings, When I create a template specifying service, duration (5–480 min), location, pre/post buffers (0–240 min), lead time (>=0 min), cutoff time (>=0 min), and number of options (1–10), Then invalid fields are flagged with inline errors and Save is disabled until all validations pass. - Given a valid template, When I save it, Then it appears in the template list with name and last-updated timestamp and is available in the composer. - Given I am composing a message and select this template, When I insert Inline Slots, Then the inserted options reflect the template defaults, pull from my real-time availability, and are converted to the recipient’s timezone. - Given I select the template in the composer, When I preview before insertion, Then I see the exact options and message that will be inserted.

Personalization Tokens Render with Fallbacks

- Given a template uses tokens {{recipient.first_name}} and {{service.name}} in subject/body, When inserting for a contact with those values, Then the tokens render with the correct values and casing. - Given a token’s data is missing for a contact, When inserting, Then the token renders with the template-defined fallback; if no fallback exists, it renders as an empty string with no token braces. - Given a template contains an unknown or malformed token, When attempting to save, Then the system blocks save and shows a validation error identifying the token. - Given preview is opened for a selected contact, When viewing the message, Then all tokens display their resolved values as they will appear to the recipient.

Conditional Rules by Client and Consult Type

- Given rules exist targeting “new client” vs “existing client” and “paid consult” vs “free consult,” When the contact matches a rule, Then the specified availability window and message variant are applied to the inserted Inline Slots. - Given multiple rules match, When inserting, Then rules are evaluated in priority order (top-to-bottom) and the first match is applied; the applied rule is indicated in the composer. - Given no rules match or the contact classification is unknown, When inserting, Then the template’s default rule is applied. - Given the contact’s classification changes, When reinserting, Then the output reflects the newly applicable rule.

Per-Channel Behavior: Email vs Chat

- Given per-channel settings are configured, When inserting via the email composer, Then Inline Slots render as an HTML block with up to the email-specific maximum number of options and include the configured subject/body text. - Given per-channel settings are configured, When inserting via a chat composer, Then Inline Slots render as compact, plain-text options or supported quick-reply buttons with up to the chat-specific maximum number of options. - Given a channel is not fully supported for rich slots, When inserting, Then the system automatically uses the channel’s fallback format without error. - Given different per-channel limits, When changing the channel, Then the number of options auto-adjusts to the channel’s limit and remains within 1–10.

Offer Frequency Limits to the Same Contact

- Given a per-template limit of N days and a global limit of M days, When attempting to insert Inline Slots for the same contact within the shorter of N or M since the last offer was sent, Then the system prevents insertion and displays a warning with the remaining wait time. - Given I have override permission, When I confirm an override, Then the system inserts the slots and records the override event with timestamp and user. - Given the contact is outside the limit window, When inserting, Then no warning is shown and slots insert normally.

Fallback to Booking Page When No Suitable Slots Exist

- Given the template’s rules, buffers, lead/cutoff times, and real-time availability yield fewer than the required number of options, When inserting, Then no time options are inserted and the configured fallback message with a booking page link is inserted instead. - Given a service, duration, and location are defined in the template, When fallback occurs, Then the booking link preselects those values and opens to the earliest available date. - Given fallback occurs, When inserting, Then the inserted content contains only the fallback message and link (no empty slot UI).

Team Presets with User-Level Overrides

- Given a team admin has published a preset template, When a user selects it, Then the preset is available for use and can be set as the user’s default. - Given the preset has locked fields (e.g., service, duration), When the user attempts to edit those fields, Then they are read-only and retain the team-defined values; unlocked fields can be edited and saved as the user’s override. - Given the admin updates a locked field in the team preset, When the user next inserts slots using that preset or an override based on it, Then the locked field reflects the updated team value. - Given a user has created overrides, When they choose Reset to team preset, Then all unlocked fields revert to team values and the override label is removed.

Tracking, Security & Compliance

"As a practice owner, I want insight into which slot inserts convert and assurance that links are secure so that I can optimize scheduling and protect client data."

Description

Track impressions, clicks, and bookings for each Inline Slots insertion to report conversion rates by channel, template, and service. Maintain an audit trail of who clicked which link and when, with slot status transitions for support and compliance. Secure slot links with signed, expiring tokens, single-use redemption, and rate limiting to deter enumeration and abuse; never expose PII in URLs. Provide link invalidation on demand and automatic expiration after booking windows close. Ensure accessibility (WCAG 2.1 AA) for slot elements and confirmation pages, and support localization of strings. Comply with GDPR/CCPA, honoring contact consent and data retention policies.

Acceptance Criteria

Conversion Tracking by Channel, Template, and Service

Given an Inline Slots insertion with identifiers insertion_id, template_id, service_id, and channel When the recipient opens the message and remote content loads Then record exactly one impression event per recipient and insertion within a 24-hour window with timestamp (UTC), channel, template_id, service_id, recipient_ref (pseudonymous), and timezone used Given the recipient clicks any slot link in the insertion When the click is received Then record a click event with insertion_id, slot_id, token_id, timestamp (UTC), and user_agent, deduplicated per recipient per slot within 5 minutes Given the recipient completes a booking from the insertion When the booking is confirmed Then record a booking event linked to the prior click and slot_id with timestamp (UTC) and service_id, and associate invoice value if applicable Given events have been collected for an insertion When metrics are requested via API or dashboard Then conversion rates (impressions→clicks→bookings) are computed and match underlying event counts within ±1% and are filterable by channel, template_id, and service_id Given a message is forwarded or viewed multiple times by the same recipient When multiple impressions occur Then de-duplication rules prevent inflated counts per recipient per insertion as defined above Given tracking is disabled by policy or consent When an impression or click occurs Then only aggregate non-identifying counts are incremented; no recipient_ref is stored

Immutable Audit Trail of Clicks and Slot Status Transitions

Given any slot link is requested When the request is processed Then append an audit record with token_id (if present), insertion_id, slot_id (if present), actor_type (recipient/system/admin), actor_ref (pseudonymous), ip (hashed or truncated per policy), user_agent, event_type (impression|click|redeem|invalid|expired), and timestamp (UTC) Given a slot status changes (Available→Held→Booked→Cancelled→Expired) When the transition occurs Then append an audit record capturing previous_status, new_status, cause (user/system/admin), and booking_ref (if applicable) Given audit records are stored When an update or delete is attempted on an existing record Then the operation is blocked (HTTP 403) and the attempt is logged as a separate audit event; records are append-only Given a support agent queries the audit trail by insertion_id or token_id When up to 10,000 related events exist Then results return in chronological order within 2 seconds and include a stable, paginated cursor API Given an audit export is requested for a contact When the export is generated Then only records within the configured retention window are included and fields are redacted per policy

Signed, Expiring, Single-Use Links with Abuse Mitigations

Given an Inline Slots URL is generated When the link is created Then it contains a signed token with at least 128 bits of entropy, scoped to insertion_id and (optionally) slot_id, includes an expiration not exceeding the configured maximum (default 7 days), and contains no PII in path or query Given HTTPS enforcement is enabled When a slot URL is requested over HTTP Then redirect using 301 to HTTPS without exposing the token in referrers or logs; server logs redact tokens Given a token is redeemed to book a slot When redemption succeeds Then mark the token as redeemed (single-use) and any subsequent redemption attempts respond 410 Gone with a localized safe message and no state change Given invalid or missing tokens exceed the configured threshold (default 10/minute, burst 20) from a single IP When further requests arrive within the window Then respond 429 Too Many Requests for 15 minutes and emit a security alert with counts and IP metadata Given enumeration patterns are detected (e.g., ≥100 unique invalid tokens in 5 minutes across IPs) When the threshold is met Then emit a high-severity alert and activate WAF blocking for the affected route

On-Demand Link Invalidation and Automatic Expiration

Given a user revokes a specific token or all tokens for an insertion via dashboard or API When revocation is confirmed Then within 60 seconds all subsequent requests with those tokens respond 410 Gone with a localized guidance message; revocation is recorded in the audit trail Given the booking window for a service or slot has closed (slot start minus configured buffer) When a token is presented Then the token is treated as expired and returns 410 Gone without changing slot status Given a token was revoked or expired When a replacement link is generated for the same recipient Then a new token is issued and the old token cannot be reactivated Given a booking was confirmed via a token When the originating token is later revoked Then the booking remains active; cancellation requires explicit action, which is captured in the audit trail

WCAG 2.1 AA Accessibility for Slots and Confirmation

Given the slot picker and confirmation pages are rendered When navigated using only a keyboard Then all interactive elements are reachable in logical order, have visible focus indicators, and no keyboard traps exist Given a screen reader user navigates the UI When slots and actions are announced Then each slot exposes an accessible name that includes date, time, timezone, availability, and selection state; errors and confirmations are announced via appropriate aria-live regions Given the UI is viewed at 200% zoom and/or high-contrast mode When layout adjusts Then content reflows without loss of information or functionality, controls remain operable, and color contrast meets or exceeds 4.5:1 for text and 3:1 for UI components Given the page language and direction are set When a locale is applied Then html lang and dir attributes reflect the locale, and RTL locales have correct reading and focus order Given icons or non-text elements convey meaning When rendered Then they have text alternatives or aria-labels that convey equivalent information

Localization of Slot UI and Confirmation

Given the recipient’s preferred locale is known or auto-detected When rendering slot UI and confirmation pages Then all user-facing strings appear in that locale with fallback to English for missing translations; no hardcoded strings remain Given date and time values are displayed When formatted for the recipient Then they follow locale conventions (12/24h, month/day order), include explicit timezone label/offset, and provide a control to change timezone Given an RTL locale (e.g., ar, he) is selected When the UI renders Then layout, alignment, and icons mirror correctly, and caret/focus behavior is appropriate for RTL Given pseudolocalization is enabled in staging When navigating the widget Then no string truncates or overflows and translation coverage is 100% Given ICU MessageFormat or equivalent is used for templates When variables (e.g., service name) are inserted Then grammar and pluralization are correct for the target locale

GDPR/CCPA Consent, Retention, and Data Subject Requests

Given a recipient is in a jurisdiction requiring consent and consent has not been granted When an impression or click occurs Then either no event is stored or only aggregate non-identifying counts are updated; no persistent recipient_ref is stored; booking remains functional Given a contact withdraws consent When processing future impressions or clicks Then identifying tracking for that contact is disabled within 24 hours and no new identifying events are stored thereafter Given a data deletion request is submitted and verified When processing the request Then personal identifiers in tracking and audit records for that contact are deleted or irreversibly anonymized within the configured retention period (max 30 days), verified by a post-deletion export Given a data export (DSAR) is requested When generating the export Then a machine-readable package of the contact’s related audit and booking interactions is produced within 30 days, excluding secrets and proprietary security data Given URLs are generated for recipients When links are created Then no PII appears in URL path, query, or fragments; tokens do not encode PII; server/application logs redact tokens and PII Given data retention policies are configured When nightly maintenance runs Then events older than the configured period are purged or aggregated, and purge operations are logged in the audit trail

Reply-to-Book

Lets clients confirm by simply replying with natural language (e.g., “Tuesday 3pm works”) or tapping a quick action in DMs. SoloPilot interprets the response, books the slot, and sends confirmations plus intake forms—asking a smart follow-up if details are unclear.

Requirements

Natural Language Parsing & Intent Resolution

"As a client, I want to reply with natural language like “Tuesday 3pm works” so that SoloPilot books the right session without making me fill out a form."

Description

Implement a parser that interprets free‑text replies to determine booking-related intents (confirm, propose time, reschedule, cancel) and extract entities such as date/time, timezone, service, duration, location, and participant. Support relative expressions (e.g., “next Tuesday at 3”, “tomorrow afternoon”), multilingual phrases, and common ambiguities with a confidence score. When confidence is below threshold or required details are missing, automatically ask targeted follow-up questions to disambiguate. Resolve services and durations against the provider’s SoloPilot catalog and client context. Integrate with SoloPilot’s messaging layer and persist a structured intent object for downstream scheduling and automation.

Acceptance Criteria

Confirm Booking via Natural Language Reply

Given a conversation with a pending proposed slot X for client C And client replies 'Tuesday 3pm works' matching slot X When the parser processes the reply Then intent = confirm And extracted datetime equals slot X in ISO 8601 And confidence >= 0.90 And serviceId and duration are inherited from the proposal context And a structured intent object is persisted with fields [intent, datetime, timezone, serviceId, duration, confidence, sourceMessageId, clientId, providerId] And a confirmation message is sent in the same thread

Propose New Time with Relative Date Expression

Given a client C with profile timezone Z and no explicit timezone in the message And client replies 'next Tuesday at 3' When the parser processes the reply at message timestamp T Then intent = propose_time And extracted datetime equals the calendar date of the next Tuesday at 15:00 in timezone Z relative to T And confidence >= 0.85 And entities [datetime, timezone] are present And a structured intent object is persisted and linked to the source message

Reschedule Request with Partial Details and Follow-up Disambiguation

Given an existing scheduled appointment A for client C in the thread And client replies 'Can we move to tomorrow?' When the parser processes the reply Then intent = reschedule And required entity time is missing And a targeted follow-up question requesting a specific time is sent within 2 seconds p95 When client replies 'any time after 2pm EST' Then timezone is resolved to America/New_York and time range start = 14:00 And overall confidence >= 0.85 after follow-up And the structured intent object is updated to include resolved entities and cross-references both messages

Cancel Intent Detection with Multilingual Phrases

Given a client C and at least one upcoming appointment And client replies in Spanish 'Necesito cancelar mi cita de mañana' When the parser processes the reply Then intent = cancel And the target appointment is resolved to tomorrow relative to client's timezone And confidence >= 0.90 And if multiple candidate appointments exist, a disambiguation message listing candidates is sent; otherwise a cancellation confirmation is sent And a structured intent object is persisted including the target appointment id

Service and Duration Resolution Against Provider Catalog

Given a provider catalog with services [Initial Consultation 60m, Follow-up 45m] And client replies 'Let's do a follow-up next Tue at 3' When the parser processes the reply Then intent includes service resolution And serviceId maps to 'Follow-up' from the catalog and duration = 45 minutes And mapping confidence >= 0.85 for auto-selection And if multiple services match above threshold, a follow-up is sent with up to 3 options sorted by confidence And the structured intent object contains serviceId and duration

Timezone and Location Extraction with Ambiguity Handling

Given client profile timezone America/Los_Angeles and provider locations [Office Downtown, Telehealth] And client replies '3pm PST at your office' When the parser processes the reply Then timezone is set from explicit 'PST' and overrides profile timezone And location resolves to 'Office Downtown' And if 'office' maps to multiple locations, a follow-up asks the client to choose And datetime is normalized to ISO 8601 and includes timezone offset And confidence >= 0.85

Structured Intent Persistence and Messaging Integration

Given any resolved or follow-up-triggered intent When parsing and resolution complete Then a structured intent object is persisted with fields [id, clientId, providerId, intentType, entities{datetime, timezone, serviceId, duration, location, participants}, confidence, messageIds, createdAt] And persistence is idempotent for duplicate sourceMessageId And persistence latency is <= 300 ms p95 from parse-complete to commit And confirmation/follow-up messages are sent via the messaging layer within 1 s p95 in the same thread

Real-Time Availability & Slot Reservation

"As a provider, I want the system to validate and hold requested times automatically so that I avoid conflicts and double bookings."

Description

Check provider availability in real time across connected calendars (SoloPilot schedule, Google, Outlook/Exchange) applying service rules (duration, buffers, locations), working hours, and double-booking policies. Convert client-proposed times to the provider’s timezone, handle daylight savings, and detect conflicts. If the requested time is unavailable, compute and propose the nearest alternatives that satisfy constraints. Support soft holds during clarification/confirmation windows to reduce race conditions, with automatic release on timeout or decline.

Acceptance Criteria

Real-Time Availability Across Connected Calendars

- Given the provider has SoloPilot, Google, and Outlook calendars connected and a service with duration/buffer/location/working hours configured - When a client proposes a specific date/time and service via Reply-to-Book - Then the system queries all connected calendars and compiles availability in real time, returning a preliminary decision within 2 seconds - And the candidate slot is validated against service duration, pre/post buffers, provider working hours, location constraints, and double-booking policy - And the slot is marked unavailable if any constraint fails; otherwise it is eligible for hold/booking

Client Proposal Converted to Provider Timezone with DST Handling

- Given the client’s timezone is known (profile or message metadata) and the provider’s timezone is set in SoloPilot - When the client replies with a natural-language time (e.g., “Tue 3pm”) that falls on or near a daylight saving transition - Then the time is interpreted in the client’s timezone and converted to the provider’s timezone accurately - And if the local time is ambiguous (DST fallback), the system asks a clarifying follow-up - And if the local time is non-existent (DST spring-forward), the system rejects the exact time and proposes the nearest valid times - And all confirmations display times in the client’s timezone, with the provider’s timezone noted

Soft Hold During Clarification to Prevent Race Conditions

- Given a candidate slot is eligible but a clarification or explicit confirmation is pending - When a soft hold is placed - Then a tentative/hold event is created in SoloPilot and mirrored to external calendars with a unique hold ID - And concurrent booking or hold attempts on the same slot are blocked with a “temporarily held” response - And the hold duration equals the configured window (default 10 minutes) and is visible to the provider - And the hold is automatically released on timeout or explicit decline and all tentative events are removed within 10 seconds - And all hold/acquire/release actions are recorded in the audit log

Nearest Alternative Slots Computation

- Given a requested time is unavailable after applying all constraints - When computing alternatives - Then at least 3 nearest valid slots within the next 7 days are generated (or all available if fewer than 3 exist) - And options are sorted by temporal proximity to the requested time and do not include slots that violate buffers, working hours, locations, or double-booking policy - And no duplicate or overlapping options are presented - And each option is returned with a booking-ready quick action

Double-Booking Policy Enforcement by Service

- Given a service has a configured double-booking policy of NoOverlap or AllowOverlapUpToN - When evaluating availability for that service - Then for NoOverlap any overlap (including buffers) with existing events marks the slot unavailable - And for AllowOverlapUpToN up to N concurrent bookings of that service are permitted; the (N+1)th overlapping request is marked unavailable - And policy changes take effect immediately for new holds and bookings

External Calendar Sync Integrity and Atomic Booking

- Given Google and/or Outlook calendars are connected - When evaluating, holding, or booking a slot - Then if the last remote sync is older than 60 seconds, a refresh is performed before finalizing the decision - And holds/bookings are written atomically: either all calendar writes succeed or the operation is rolled back and the user is notified - And on external API failure or rate limiting, the system retries up to 3 times with exponential backoff and surfaces a clear, actionable error - And a final conflict check is performed after successful writes; if a conflict is detected, the operation is rolled back and alternatives are proposed

Channel Connectors & Quick-Action CTAs

"As a client, I want tappable confirm buttons in my messages so that I can book instantly without typing."

Description

Provide inbound/outbound connectors for common channels (SMS, WhatsApp Business, email, in-app chat), normalizing messages to a unified format. Where supported, include quick-action buttons (Confirm, Suggest Alternatives, Add to Calendar) that trigger booking flows without typing; otherwise, fall back to smart-reply guidance and deep links. Ensure message templates, delivery status tracking, and retry logic. Expose webhooks for third-party DMs and a pluggable interface to add new channels without core changes.

Acceptance Criteria

Inbound Message Normalization

Given inbound SMS, WhatsApp Business, email, and in-app chat messages are received When SoloPilot ingests each message Then a normalized payload is produced with fields: channel, external_message_id, sender_handle, thread_id, received_at (ISO 8601 UTC), text, attachments[], cta_capabilities[] And no channel-proprietary fields are present in the emitted payload And the payload is available to downstream booking services within 2 seconds of provider receipt Given an inbound message includes attachments (image or file) When normalized Then each attachment includes type, size_bytes, filename, and a temporary URL valid for at least 15 minutes Given a duplicate delivery (same external_message_id and channel) When processed Then deduplication ensures exactly-once emission to downstream consumers and idempotent persistence

Quick-Action CTA Rendering and Booking Handling

Given a message template includes CTAs: Confirm, Suggest Alternatives, Add to Calendar When sent to WhatsApp Business and in-app chat Then recipients see three interactive buttons labeled accordingly and supported by the channel Given a recipient taps Confirm on a proposed slot When processed Then the appointment is created, a confirmation message is sent on the same channel, and the intake form link is delivered Given a recipient taps Suggest Alternatives When processed Then the system returns three nearest available slots respecting provider working hours and calendar constraints in a single interactive reply, and each option can be booked with one tap Given a recipient taps Add to Calendar after booking When processed Then an .ics file (email or link) and Google/Apple calendar deep links are provided and open a prefilled event Given a channel does not support a specific CTA When rendering Then that CTA is omitted and a fallback instruction is included

Smart-Reply Fallback and Deep Links on Unsupported Channels

Given an SMS or plain-email client that does not support interactive buttons When a template with CTAs is sent Then the message includes smart-reply guidance (e.g., Reply "Confirm" to book, "Alt" for options, or propose a time) and a deep link to the booking page Given a recipient replies with natural language such as "Tuesday 3pm works" When interpreted Then the time is resolved in the recipient's timezone, availability is checked, and the booking is confirmed in one step with a confirmation message returned Given a reply is ambiguous (e.g., "next week" or multiple times) When interpreted Then a clarifying question is sent requesting specific dates/times, and if no response is received within 15 minutes, one reminder is sent before closing the prompt Given a reply explicitly requests alternatives ("alt", "other times") When interpreted Then three valid alternative slots are returned and can be booked by replying with the option number or using the deep link

Message Templates, Personalization, and Localization

Given a message template with variables {client_name}, {slot_time}, {timezone}, {business_name} When rendered for any channel Then variables are populated correctly, date/time is formatted per the recipient locale, and channel-unsafe markup is stripped or downgraded without breaking content Given a recipient locale preference (e.g., en-US, es-ES) When sending a template Then the localized template variant is selected and date/time strings are formatted per locale Given an SMS message exceeds 480 characters after rendering When sending Then the text is segmented, ordered, and labeled to preserve meaning without breaking URLs or deep links Given a template fails validation (missing variables, invalid placeholders) When attempting to send Then sending is blocked and a descriptive error is returned in logs and UI

Delivery Status Tracking and Retry Logic

Given an outbound message is sent When provider callbacks or status APIs are received Then the message status in SoloPilot updates to one of: queued, sent, delivered, read (only where supported), or failed, within 5 seconds of provider event Given a transient failure occurs (HTTP 5xx, network timeout) When sending Then retries use exponential backoff (approximately 2s, 10s, 30s) up to 3 attempts and ensure at-most-once delivery Given a permanent failure occurs (HTTP 4xx not retryable) When sending Then no retries are attempted and the message is marked failed with provider error code and human-readable reason Given a message ultimately fails after max retries When status is updated Then the user is notified in-app with a one-click option to retry or switch channel

Webhooks for Third-Party DMs (Inbound and Outbound)

Given an inbound webhook endpoint is configured for third-party DMs When a POST arrives with a valid HMAC signature, content hash, and idempotency key Then the server responds 200 within 200ms, enqueues processing, and duplicate POSTs do not create duplicate messages Given an inbound webhook request has an invalid or missing signature When received Then the server responds 401 and the payload is discarded Given outbound status webhooks are configured for a partner When a message status changes to sent, delivered, read, or failed Then a signed POST is sent to the partner endpoint within 3 seconds; on 5xx responses, retries occur up to 3 times with exponential backoff

Pluggable Channel Adapter Interface

Given a new channel adapter implementing the interface (send, parseInbound, capability flags: supports_ctas, supports_read_receipts) When registered via the plugin registry and feature flag enabled Then messages can be sent and received through the new channel without modifying core services Given an adapter reports supports_ctas=false When rendering a message with CTAs for that channel Then the system automatically falls back to smart-reply guidance and deep links Given contract tests are executed against the adapter When run in CI Then all interface tests pass including schema conformance for inbound normalization and successful send in sandbox Given the adapter is disabled at runtime When there are in-flight retries Then retries are canceled gracefully, no new sends are attempted, and users are prompted to choose another channel

Identity Matching & Consent Capture

"As a provider, I want replies linked to the correct client and consent recorded so that bookings are accurate and compliant."

Description

Map incoming messages to the correct client record using channel identifiers (phone, email, WhatsApp ID) and verification heuristics. When ambiguous, request lightweight verification (e.g., last name or code) before booking. Record explicit consent for booking actions initiated via messaging and log the message thread as proof. Enforce provider-defined policies (e.g., no bookings from unknown numbers, minors, or blocked contacts). Maintain an auditable trail of who confirmed, when, via which channel, and from which IP/device metadata where available.

Acceptance Criteria

Deterministic Match by Channel Identifier

Given an inbound message arrives via SMS, email, or WhatsApp from an identifier that maps to exactly one active client record And provider policies allow bookings from this contact When the message contains clear booking confirmation intent for an available slot Then the system associates the message with that client and creates/updates the booking within 10 seconds And the system records explicit consent by storing the original message ID, full text, timestamp (ISO 8601), channel, and sender identifier on the booking record And the system sends confirmation and any required intake forms to the client and notifies the provider

Ambiguous Match Requires Lightweight Verification

Given an inbound message arrives where the channel identifier matches multiple client records or the heuristic confidence score is below 0.90 When the system cannot uniquely determine the client Then the system requests lightweight verification (e.g., last name or 4‑digit code) and pauses booking When the correct verification value is received within 15 minutes Then the booking proceeds and the verification method and hashed value are stored with the booking and audit log When verification fails or times out Then no booking is created and the client is informed how to proceed; the attempt and reason are logged

Unknown Sender Blocked per Provider Policy

Given the provider policy is set to disallow bookings from unknown identifiers When an inbound message is received from a phone/email/WhatsApp ID not linked to any active client record Then the system declines to create a booking and responds with a policy message and optional onboarding link And the system logs the attempt with reason "policy_unknown_contact", channel, identifier, and timestamp And no calendar holds or invoices are created

Minor or Age-Restricted Contact Enforcement

Given the provider policy disallows bookings from minors (or below a configured age threshold) And the matched client record indicates an age below the threshold When the client attempts to confirm a booking via messaging Then the system refuses the booking, sends a compliant guidance message (e.g., contact guardian/provider), and logs the policy enforcement And no booking, intake, or invoice is created

Blocked Contact Attempt Rejection

Given a contact is marked as Blocked in the provider's SoloPilot workspace When the blocked contact sends a booking-confirmation message via any supported channel Then the system rejects the request, does not create or modify any booking, and does not send intake forms And the system logs the attempt with reason "policy_blocked_contact" including channel, identifier, and timestamp And the provider receives a non-intrusive notification (configurable)

Consent Capture and Auditable Proof on Message-Initiated Booking

Given any booking is created or updated based on a client message or quick action tap When the booking is finalized Then the booking record includes: who confirmed (client name and ID), channel, original message ID(s), message text snippet, timestamp (ISO 8601 with timezone), match confidence score, verification method (none/last_name/code), and hashed verification value And where available, IP address and device metadata from quick action deep links are captured and attached And the full message thread is linked and exportable as a PDF/JSON audit artifact And the provider can view this consent and thread from the booking details screen

Heuristic Match with Smart Follow-up and Traceability

Given an inbound message has partial identifiers (e.g., shared family phone, name variation) and prior conversation history exists When heuristic signals (prior threads in last 180 days, name similarity, timezone alignment) produce a confidence score ≥ 0.90 Then the system selects the matched client, proceeds with booking, and records the contributing signals and score in the audit log When the score is < 0.90 Then the system issues a smart follow-up asking for a clarifying detail (e.g., last name) before booking And all decision points (scores, prompts, responses) are time-stamped and retrievable

Confirmation, Intake, and Post-Booking Automations

"As a provider, I want confirmed bookings to auto-send confirmations and intake forms so that I don’t have to chase clients or set things up manually."

Description

Upon successful intent resolution and availability check, auto-create the appointment in SoloPilot, send a confirmation message plus a calendar invite, and attach required intake forms based on service type. Trigger existing SoloPilot automations (reminders, pre-session questionnaires, payment requests if applicable). Include reschedule/cancel smart links and support dynamic message templates with personalization tokens. Update the client record and prepare session artifacts (notes template, billing placeholders) to streamline session-to-invoice workflows.

Acceptance Criteria

Auto-create Appointment After Intent and Availability Confirmation

Given a client reply has been resolved to a specific service, date/time, and timezone and the availability check returns the slot as available When the booking is finalized Then an appointment record is created within 5 seconds with fields: clientId, serviceId, startAt (ISO 8601 with timezone), endAt, location, bookingChannel, sourceMessageId, and status "Confirmed" And no overlapping confirmed appointment exists for the same provider/resource at that time And the appointment is associated to the correct provider calendar/workspace And the creation is idempotent based on a deterministic booking key (no duplicate appointments on retries)

Confirmation DM and Calendar Invite Delivery

Given an appointment is created When sending confirmations Then the client receives a confirmation message in the original conversation channel within 5 seconds containing: service name, date/time in client timezone, location/meeting link, reschedule link, and cancel link And an ICS calendar invite is emailed to the client's primary email with organizer set to the provider, including conferencing details and reminder defaults And the provider calendar reflects the new event within 10 seconds And failures are logged and retried up to 3 times with exponential backoff; on persistent failure, the provider is notified

Service-Based Intake Forms Attachment

Given the booked service has required intake forms configured When the confirmation is generated Then secure intake form links (authenticated or one-time token) are created, assigned to the client, and included in the confirmation message and invite description And known client/profile fields are prefilled And the due date is set to 24 hours before session start (or immediate if booked within 24 hours) And intake completion status is visible on the appointment record And access links expire at session start

Trigger Reminders, Questionnaires, and Payment Requests

Given automations are configured for the service When the appointment is confirmed Then reminder jobs are scheduled at the configured offsets (e.g., 48h and 2h before) with the correct channel(s) And a pre-session questionnaire is scheduled to send immediately after confirmation and re-sent at the next reminder if incomplete And if the service requires payment or deposit, a payment request is generated with correct amount, currency, due date, and included link And idempotency ensures only one set of automations and one payment request per appointment even on retries or updates

Reschedule and Cancel Smart Links Functionality

Given the client receives confirmation containing reschedule and cancel links When the client clicks the reschedule link Then they see real-time availability for the same service/provider and can select a new slot And upon rescheduling, the original appointment is updated (not duplicated), automations are recalculated to the new time, and updated confirmations and invites are sent When the client clicks the cancel link Then the appointment status becomes "Canceled", cancellation policy rules are applied (fees/refunds as configured), and both parties are notified And the links are single-appointment scoped, single-use, and expire at session start

Dynamic Message Templates With Personalization Tokens

Given a confirmation template contains tokens such as {client.firstName}, {service.name}, {session.datetime}, {session.location}, {rescheduleLink}, {cancelLink}, {intakeLinks}, {paymentLink} When generating the confirmation message and invite description Then all tokens resolve from client, service, and appointment data with locale-aware date/time and timezone formatting And missing optional fields use safe fallbacks (e.g., {client.firstName} -> "there") without exposing raw tokens And unknown tokens are removed and logged as warnings And the final message contains no unresolved braces and respects channel limits (e.g., <= 1000 chars for SMS)

Client Record Update and Session Artifacts Preparation

Given the appointment is confirmed When post-booking tasks run Then the client record is updated with lastBookedAt, upcomingSessionsCount, and a service history entry referencing the appointment And a notes template appropriate to the service is created and linked to the appointment And billing placeholders are created with line items per service pricing, duration, and tax configuration, enabling one-click session-to-invoice And the end-to-end post-booking workflow completes within 10 seconds and is idempotent across retries

Admin Controls, Policies, and Templates

"As a provider, I want to configure how Reply-to-Book behaves across my services and channels so that it matches my policies and brand."

Description

Offer configuration for enabling Reply-to-Book per service and channel, setting default follow-up questions, confirmation templates, office hours, buffers, lead/notice periods, and reschedule/cancellation rules. Provide per-service and per-channel toggles, branding options, and language/locale settings. Allow overrides for VIP clients and exceptions. Include RBAC so only authorized roles can change policies. Provide a sandbox/preview mode to test flows before enabling in production.

Acceptance Criteria

Per-Service and Per-Channel Enablement

Given a workspace has Service A with channels Email, SMS, WhatsApp, and In-App DM, When an Admin toggles Reply-to-Book ON for SMS for Service A and OFF for other channels, Then only SMS inbound replies for Service A are interpreted and auto-booked. Given Reply-to-Book is OFF for a channel, When a client replies on that channel, Then the system does not attempt NLP parsing and sends the configured fallback message for disabled channels. Given Reply-to-Book is ON for a channel, When a client taps a quick action in that channel's DM, Then the booking flow is initiated for the configured service and channel. Given a service is archived or paused, When viewing its channel toggles, Then toggles are disabled and Reply-to-Book is inactive for that service.

Default Follow-Up Questions and Clarifications

Given an Admin defines default follow-up questions for missing duration and location for Service A, When a client reply lacks duration or location, Then the system sends the configured follow-up prompts in order until required fields are provided. Given validation rules are set for follow-up answers, When a client reply is ambiguous (e.g., "later afternoon"), Then the system sends the mapped clarification prompt and does not book until a valid value is supplied. Given a maximum follow-up attempts threshold of 2 is configured, When the threshold is exceeded, Then the system sends the escalation/fallback template and stops auto-booking.

Confirmation Templates, Branding, and Locale

Given an Admin sets per-channel confirmation templates with placeholders {client.first_name}, {service.name}, {start_time_local}, and selects Brand Theme X and locale fr-FR, When a booking is confirmed via SMS, Then the rendered message uses Theme X branding, is localized to fr-FR, and placeholders resolve with booking data. Given a placeholder lacks data and a default is provided (e.g., {location|TBD}), When rendering a confirmation, Then the default value is used without error. Given channel-specific length limits (e.g., SMS 160 characters per segment) are defined, When rendering a confirmation, Then the preview shows segment count and outbound messages are sent split without truncation. Given time zone differences between provider and client, When rendering {start_time_local}, Then the time is shown in the client's locale and time zone while honoring the provider's calendar time.

Office Hours, Buffers, and Lead Time Enforcement

Given office hours are set to Mon–Fri 09:00–17:00 and a 30-minute buffer before and after sessions, When a client proposes "Tuesday 5pm", Then only slots that start within office hours and respect buffers are considered bookable. Given a minimum lead time of 24 hours and a maximum scheduling window of 60 days are configured, When a client proposes a time within 8 hours from now or beyond 60 days, Then the system declines and proposes the next available times within policy. Given daylight saving transitions affect the provider's time zone, When computing availability for a client in a different time zone, Then suggested times adhere to provider office hours and are displayed in the client's local time.

Reschedule and Cancellation Rules

Given Service A has reschedule cutoff 12h and cancellation cutoff 24h with fee policy "charge 50% inside cutoff", When a client requests a change inside these windows, Then the system enforces the rule (block, require approval, or apply fee) and sends the corresponding template. Given an exception rule "waive first violation" is configured, When a first-time client cancels inside cutoff, Then the fee is waived and the exception is recorded. Given approvals are required for reschedules inside cutoff, When a client requests reschedule within 6 hours, Then the request is set to pending approval, no calendar changes are made, and both parties are notified.

VIP Overrides and Exceptions

Given a client is marked VIP with overrides "ignore lead time" and "allow after-hours", When the VIP replies "tonight 8pm", Then the system surfaces slots outside office hours and bypasses lead-time checks only for that client. Given VIP overrides are limited to Service A, When the VIP requests Service B without overrides, Then standard policies apply. Given override usage must be auditable, When an appointment is booked or changed due to a VIP override, Then an audit log entry captures client, policy bypassed, actor, timestamp, and change details.

RBAC, Audit, and Sandbox/Preview Mode

Given roles Owner, Admin, and Staff exist and only Owner/Admin have "Configure Reply-to-Book Policies", When a Staff user attempts to save a policy change, Then the save is blocked with a 403 error and an in-UI permission notice. Given a privileged user updates any policy or template, When the change is saved, Then an immutable audit record is created with user, timestamp, environment (Sandbox/Production), fields changed, and old/new values. Given Sandbox mode is enabled, When an Admin uses "Preview flow" to simulate a client reply "Tuesday 3pm" for Service A, Then the system runs the full flow in isolation (no production calendar writes or messages), renders the client/host messages, and shows what would be booked. Given "Promote from Sandbox" is used, When the Admin confirms promotion, Then the sandbox configuration is copied to Production with versioning and a success confirmation, leaving sandbox data intact.

Observability, Error Handling, and Feedback Loop

"As a provider, I want visibility into bookings and tools to correct misinterpretations so that the system gets more accurate over time."

Description

Implement end-to-end tracing and structured logs for every message-to-booking flow, with metrics on parsing accuracy, time-to-book, channel conversion, and failure reasons. Surface an inbox view showing the parsed intent, confidence, and decision path, with a one-click correction UI that retrains or updates parsing rules. Provide alerts for repeated failures or channel outages and automatic fallbacks (e.g., send a booking link) when confidence or connectors fail. Support exportable audit logs and privacy controls for message retention and redaction.

Acceptance Criteria

Traceability of Message-to-Booking Flow

Given a client reply arrives via any supported channel When the message is processed through ingestion, parsing, availability lookup, booking, and notification Then a single correlation_id is generated and propagated to all spans and structured logs And 99% of flows (success and failure) contain spans for each stage with start and end timestamps And each trace includes tenant_id, workspace_id, channel, message_id, client_id (pseudonymous), intent, confidence, decision, outcome, error_code, retry_count, and booking_id when created And p50, p95, and p99 end-to-end time-to-book metrics are emitted per tenant and per channel And on retries, spans are linked to the original correlation_id with attempt numbers And traces are queryable by correlation_id within 5 minutes of event time

Structured Logging with Redaction and Retention Controls

Given structured logging is enabled for a workspace When events are written Then logs are emitted as JSON with schema_version, event_type, event_time (UTC), correlation_id, message_id, tenant_id, channel, and outcome fields And raw message content is stored only when message_retention=true for the workspace And when message_retention=false, raw message bodies are irreversibly redacted before persistence and within 5 minutes of ingestion And redaction removes emails, phone numbers, and free-text names, replacing with consistent tokens, and sets redaction_flags accordingly And retention period is configurable per workspace (7–365 days) with default 90 days, and data older than the period is purged daily And a Delete-My-Data request for a client identifier purges related messages and logs within 24 hours and creates an audit entry And only Owner and Support Admin roles can view unredacted content when retention=true

Metrics for Parsing Accuracy, Time-to-Book, Conversion, and Failures

Given metric collection is enabled When conversations progress from first reply to booking or failure Then parsing intent accuracy and slot-fill accuracy are computed daily from correction labels and a held-out set And last-30-day English intent accuracy >= 90% and slot accuracy >= 85% per channel with at least 500 samples And time-to-book is measured from first client reply to booking creation; p50 <= 20s and p95 <= 90s per channel And channel conversion rate (%) is computed as bookings / eligible conversations within 24h and reconciles within 1% of the bookings database And failure reasons are categorized using a controlled taxonomy; “unknown” category accounts for < 5% of failures And all metrics are visible in a dashboard with filters (date range, channel, tenant) and update latency <= 5 minutes And metrics are exportable as CSV via UI and API

Inbox Decision Path with One-Click Correction

Given a user opens the Reply-to-Book inbox for a conversation When the item is displayed Then it shows parsed intent, extracted slots (date, time, duration), confidence [0–1], and the decision path steps that led to the outcome And 95% of inbox items load in <= 1s and render the decision path in <= 500ms after data fetch When the user applies a one-click correction to intent and/or slots Then the system reprocesses the conversation within 10s, updates the outcome, and optionally sends a corrected client message And the correction is recorded in an immutable audit log with user_id, before/after values, timestamp, and correlation_id And a training example is created; rules updates apply immediately and model updates are applied within 30 minutes And only users with the “Can Correct Parsing” permission can apply corrections And the user can undo a correction within 5 minutes; any client message sent due to the correction is retracted or clarified if the channel supports it

Alerts for Failures/Outages and Automatic Fallbacks

Given operational monitoring is active When 5 or more parse or booking failures occur for a tenant within 10 minutes or the failure rate exceeds 10% over 30 minutes Then an alert is sent to the tenant’s configured channels (email, Slack, webhook) within 60 seconds including top failure reason and three sample correlation_ids When the connector error rate for a channel exceeds 20% for 5 minutes Then the channel is marked degraded, a status event is emitted, and alerts are sent When intent confidence < 0.75 or a required slot is unresolved after one clarification Then the client is sent a booking link prefilled with known details, the operator is notified in the inbox, and the fallback is logged When a connector send fails or times out Then the system retries with exponential backoff up to 3 attempts with idempotency keys and falls back to an alternate channel or email if available And the system guarantees exactly-once booking confirmation or booking-link delivery per conversation

Exportable Audit Logs API and UI

Given an authorized user requests an export of audit logs When filters (date range, tenant, channel, outcome, confidence range) are applied and format (NDJSON or CSV) is selected Then the export includes event_time (UTC), correlation_id, message_id, intent, confidence, decision, outcome, error_code, booking_id, redaction_flags, and actor metadata And redacted content is excluded or replaced with “[REDACTED]” unless the workspace allows retention and the requester has permission And exports up to 100,000 rows are generated within 2 minutes; larger exports up to 1,000,000 rows stream with pagination And the download is provided via a pre-signed URL valid for 24 hours and includes a SHA-256 checksum; the export request is logged immutably And the API enforces a limit of 5 concurrent exports per tenant and returns 429 when exceeded

Signature Enrich

Scrapes email signatures and social profiles to auto-create complete contacts—name, phone, company, timezone, and locale—linked to the thread. Eliminates manual entry and keeps records accurate for billing, reminders, and compliance.

Requirements

Signature Parsing Engine

"As a solo practitioner, I want email signatures automatically parsed into contacts so that I don’t waste time on manual data entry and can trust my records for billing and reminders."

Description

Implement a server-side parser that detects and extracts structured contact data from email signatures on inbound and outbound messages. Parse name, title, company, phone(s), email, website, physical address, and optional cues (timezone tokens, locale indicators). Normalize and validate data (e.g., E.164 for phones, RFC 5322 for emails), strip legal disclaimers/footers, and handle multi-language signatures and forwarded/replied content. Run on message ingestion with idempotency keys tied to message IDs. Output field-level confidence scores and provenance (signature vs. header). Seamlessly integrates with SoloPilot’s contact model to auto-populate new or existing contacts and link them to the originating thread for downstream scheduling, invoicing, reminders, and automations.

Acceptance Criteria

Inbound Email With Standard Signature

Given an inbound message containing a conventional signature block with name, title, company, phone, email, website, and physical address When the message is ingested by the Signature Parsing Engine Then each field is detected and extracted into structured fields And phone numbers are normalized to E.164 format And email addresses validate against RFC 5322 And websites are normalized to include scheme and punycode where needed And physical addresses are parsed into street, city, region/state, postal code, and country And field-level confidence scores in the range [0.0, 1.0] are returned And field-level provenance is set to "signature" for signature-derived values And a new contact is created in the SoloPilot contact model populated with the extracted fields And the contact is linked to the originating message thread

Multi‑Language Signature Parsing With Locale/Timezone Cues

Given an inbound message whose signature is written in a non-English language using UTF-8 and locale-specific labels (e.g., "Tél.", "Empresa", "Dirección") possibly including timezone tokens (e.g., "PST", "GMT+1") When the message is ingested by the Signature Parsing Engine Then name, title, company, phone, email, website, and address are correctly detected despite non-English labels And Unicode characters (e.g., accents/diacritics) are preserved in stored fields And phone numbers are normalized to E.164 and emails validate against RFC 5322 And address components are parsed respecting locale conventions where applicable And if locale indicators are present, the contact locale is set to a valid BCP 47 tag with a confidence score; otherwise locale is left unset And if timezone tokens are present, the contact timezone is set to a valid IANA timezone with a confidence score; otherwise timezone is left unset And field-level provenance is set to "signature" for signature-derived values

Footer and Legal Disclaimer Stripping

Given a message that includes a signature followed by legal disclaimers, marketing banners, or unsubscribe footers When the message is ingested by the Signature Parsing Engine Then non-signature sections (disclaimers, banners, unsubscribe text) are excluded from parsing And no disclaimer or marketing text is persisted into any contact field And no confidence score is emitted for excluded sections And signature fields, if present, are still extracted and stored as structured data with provenance "signature"

Outbound Message Parsing With Quoted Recipient Signature

Given an outbound reply or forward sent from SoloPilot that includes the recipient's prior signature in quoted content When the message is ingested by the Signature Parsing Engine on send Then the engine extracts contact data from the most recent recipient signature present in the quoted content And the engine does not extract data from the SoloPilot user's own signature And extracted fields carry provenance "signature" and are integrated into the contact model And the contact is created or updated and linked to the associated outbound thread

Forward/Reply Chain Signature Selection

Given a message containing multiple quoted replies/forwards with several historical signatures When the message is ingested by the Signature Parsing Engine Then only the most recent relevant signature closest to the top of the thread is considered for extraction And older signatures in deeper quoted sections are ignored And quoted original message headers (e.g., "From:", "Sent:") are not misclassified as signature fields And exactly one contact create/update operation is performed for this message

Idempotent Processing By Message ID

Given that the same message (same provider message ID) may be delivered or retried multiple times When the message is ingested multiple times with the same idempotency key derived from the message ID Then parsing results are applied at most once And no duplicate contacts are created And no duplicate phone/email entries are added to an existing contact And subsequent ingestions return the same results without additional side effects

Existing Contact Merge With Confidence and Provenance

Given parsed signature fields that match an existing contact by normalized email or phone When integrating parsed results into the SoloPilot contact model Then fields are updated only if the new value has a higher confidence score than the stored value or the stored value is null And field-level provenance is stored as provided ("signature" or "header") per field And normalized matching prevents duplicate phone/email entries And the contact remains linked to the originating thread after the update

Profile Enrichment APIs

"As a consultant, I want contacts auto-enriched from public profiles so that I have complete, up-to-date details without manual research."

Description

Augment parsed signature data with public profile enrichment via approved third-party APIs (e.g., company domain lookup, social profiles) using email and domain as keys. Respect vendor ToS, rate limits, and privacy requirements. Cache results with TTL, implement exponential backoff/retry, and maintain per-vendor credentials in secure storage. Enrich missing attributes such as company size/industry, job title, LinkedIn URL, and city/region for improved timezone inference. Store field-level provenance and confidence along with timestamps for refresh governance. Integrate with SoloPilot automations by enriching asynchronously and emitting events when contact records are updated.

Acceptance Criteria

Asynchronous Enrichment Populates Missing Contact Fields

Given a contact is created from a parsed email signature containing a valid email address and company domain When the enrichment worker processes the contact asynchronously Then the system queries only approved vendors using email and domain as keys And fills only missing fields among: job_title, company_size, company_industry, linkedin_url, city, region And stores each populated field with provenance {vendor, method, fetched_at} and a confidence score between 0.0 and 1.0 And updates the contact record in the database And emits a contact.enriched event with the changed fields and their provenance And completes within 120 seconds under nominal load

Rate Limiting, Backoff, and Retry Compliance

Given a vendor returns HTTP 429 or a request exceeds configured rate limits When the enrichment worker schedules subsequent requests Then exponential backoff with jitter is applied starting at 1s and doubling up to a max delay of 120s And Retry-After headers are honored when present And retries are capped at 3 attempts per vendor per contact per run And the system does not exceed the configured per-vendor requests-per-minute threshold And structured logs and metrics record throttling, retries, and outcomes And the attempt is marked deferred when retries are exhausted

Per-Vendor Credential Security and Isolation

Given vendor API credentials are configured When the enrichment worker authenticates to a vendor Then credentials are retrieved from secure storage at runtime and never hardcoded or logged And credentials are encrypted at rest and in transit And access to credentials is audited with timestamp, actor, and purpose And credentials are isolated per vendor and environment (dev, stage, prod) And credential rotation is supported without downtime via versioned secrets

Caching with TTL and Field-Level Refresh Governance

Given an enrichment response exists in cache for a contact When a new enrichment is requested within the configured TTL (e.g., 30 days) Then cached values are returned and no vendor calls are made And each field retains its own fetched_at timestamp and TTL When the TTL for a specific field expires Then only that field is re-queried from vendors And existing values are not overwritten by lower-confidence results unless a manual override flag is set And last_refresh_at and next_refresh_at are recorded per field

Privacy, Consent, and Vendor ToS Enforcement

Given a contact or workspace has do_not_enrich=true or resides in a restricted region When an enrichment job is triggered Then the job is skipped and the reason is recorded without calling vendors And no personal data is sent to vendors outside the configured allowlist And vendor ToS requirements (e.g., attribution or purpose headers) are satisfied on each request And a compliance log entry is created for each vendor call with purpose and fields requested

Idempotent Updates and Event Delivery

Given an enrichment job runs multiple times for the same contact due to retries or schedules When no field values would change Then the contact record is not updated and no event is emitted When at least one field value changes Then updates are applied using an idempotency key per contact+vendor+payload hash And a single contact.enriched event is emitted containing only changed fields, provenance, confidence, and a correlation_id And downstream consumers can deduplicate via the idempotency key

Timezone and Locale Inference from Enriched Data

Given city and region are enriched and a company domain TLD is available when applicable When timezone and locale inference runs Then contact.timezone is set using a maintained mapping with at least 95% coverage of supported cities And contact.locale is set from locale hints (email headers, domain TLD, or vendor-provided locale) when available And user-specified timezone or locale is never overwritten And timezone_source and timezone_confidence are stored in provenance And a contact.timezone_inferred event is emitted only if the timezone changes

Contact Creation & Deduplication

"As a therapist, I want new contacts created and linked to the email thread without duplicates so that my client list stays clean and workflows run reliably."

Description

Create or update SoloPilot contacts based on parsed/enriched data with robust deduplication. Match primarily on email, secondarily on phone and fuzzy name+company, with tunable thresholds. Merge records safely using field precedence rules and confidence scores; never overwrite user-locked fields. Ensure thread linking: associate the email thread/conversation ID with the contact and client workspace. Provide atomic upsert operations, concurrency safety, audit trails, and rollback. On success, trigger downstream workflows (e.g., session-to-invoice, reminders) using the enriched contact profile.

Acceptance Criteria

Primary Email Upsert and Thread/Workspace Linking

Given a parsed/enriched contact payload containing email E and email thread ID T from workspace W When an upsert is requested and no existing contact has email E Then a new contact is created with email=E, the contact is linked to thread T and workspace W, and the operation returns contact_id and status=created Given a parsed/enriched contact payload containing email E and email thread ID T from workspace W and an existing contact with email E exists When an upsert is requested Then that contact is updated per field precedence rules, thread T is associated to the contact if not already, the operation returns the existing contact_id and status=updated, and no additional contact is created Given the same payload is submitted multiple times with the same idempotency key K within 60 seconds When upserts are requested Then exactly one create/update occurs and all responses include the same contact_id and status=idempotent

Phone Fallback Matching Without Email

Given a payload without email but with phone P When an upsert is requested Then phone P is normalized to E.164 and matching is performed on the normalized phone Given normalized phone P uniquely matches an existing contact When an upsert is requested Then that contact is updated per precedence rules and the operation returns contact_id and status=updated Given normalized phone P matches more than one contact When an upsert is requested Then no automatic merge occurs, a new contact is not created, the operation returns status=ambiguous with the list of candidate contact_ids, and an audit entry records the ambiguity Given normalized phone P matches no existing contact When an upsert is requested Then a new contact is created with phone=P and the operation returns contact_id and status=created

Fuzzy Name+Company Matching with Tunable Thresholds

Given a payload with name N and company C but no email or phone and the fuzzy threshold is set to 0.85 When an upsert is requested Then a similarity score S is computed against existing contacts using name+company and both S and the threshold are recorded in the audit Given S >= 0.85 and the top match is unique When an upsert is requested Then the top-matched contact is updated per precedence rules and the operation returns contact_id and status=updated Given S < 0.85 When an upsert is requested Then a new contact is created and the operation returns contact_id and status=created Given the threshold is changed to 0.90 via settings When a subsequent upsert with the same payload is requested Then the new threshold 0.90 is used in the decision and the decision outcome reflects the new threshold Given multiple contacts have scores within 0.02 of the top score and >= threshold When an upsert is requested Then no automatic merge occurs and the operation returns status=ambiguous with candidate contact_ids

Field Precedence and User-Locked Protection

Given field precedence rules user_locked > user_entered > enriched > parsed > empty When a merge occurs Then any user_locked field value remains unchanged and no lower-precedence source overwrites a higher-precedence value Given a target contact has blank timezone and the incoming payload supplies timezone TZ from enriched data When a merge occurs Then contact.timezone is set to TZ and field_provenance.timezone=enriched Given a target contact has locale L1 from user_entered and the incoming payload supplies locale L2 from parsed When a merge occurs Then locale remains L1 and an audit entry records that L2 was ignored due to precedence Given conflicting phone formats representing the same number When a merge occurs Then the stored phone value is normalized to E.164 and duplicates are collapsed to a single canonical entry Given a user locks a field after a merge When a subsequent upsert attempts to change that field Then the value is not changed and the audit records a protected_field_skip

Atomic Upsert and Concurrency Safety

Given two upsert requests for the same email E arrive within 100 ms When processed concurrently Then exactly one contact is created or updated, both requests return the same contact_id, and no duplicate records exist Given an upsert touches multiple tables (contacts, contact_threads, audit) When a downstream write fails Then the entire transaction is rolled back, the contact state remains as before the upsert, and an audit entry with status=failed and reason is recorded Given version V of a contact record When an upsert is applied Then the record version increments to V+1 and subsequent concurrent upserts with stale versions are retried or rejected with a 409 conflict Given high concurrency (>= 50 parallel upserts for the same email E over 10 seconds) When processed Then p99 upserts complete without deadlocks and the final state reflects a single consistent record

Audit Trail and Rollback

Given a successful upsert or merge When the operation completes Then an audit log is persisted containing contact_id, actor=system, source=Signature Enrich, timestamp, thread_id, workspace_id, fields_changed with before/after/provenance, match_strategy, confidence_scores, decision, and idempotency_key Given an audit entry A for contact C When a rollback to A is requested by an authorized user Then all fields revert to the values recorded in A, field provenance is restored, and a compensating audit entry is created with action=rollback referencing A Given a rollback is executed When downstream systems had been triggered by the original upsert Then compensating events are emitted to prevent duplicate billing/reminders and no additional duplicates are created Given an audit retention policy of at least 365 days When queried Then audit entries for contact C within that period are retrievable and immutable

Downstream Workflow Triggers and Idempotency

Given a successful create or update with a non-ambiguous decision When the upsert transaction commits Then downstream workflows (e.g., session-to-invoice, reminders) are triggered with the enriched contact profile and workspace context, and each trigger includes a correlation_id tied to the upsert Given the same upsert is retried with the same idempotency key K When processed Then no duplicate downstream workflows fire and responses return status=idempotent with the original correlation_id Given a downstream dispatch temporarily fails When retries occur Then exponential backoff is applied up to N attempts and on eventual success only one workflow instance is active, with failure and retry_count recorded in audit Given the upsert outcome is status=ambiguous When processing triggers Then no downstream workflows are emitted

Timezone and Locale Inference

"As a coach, I want timezone and locale auto-detected so that scheduling and reminders are sent at the right time and in the right format for each client."

Description

Infer contact timezone and locale using a layered approach: signature tokens (e.g., PT, CET), enriched profile location, email header Received paths, and phone country codes. Map to IANA tz database identifiers and BCP 47 language tags. Provide confidence scoring and fallbacks (e.g., company HQ) with a threshold for auto-apply; otherwise route to review. Update SoloPilot scheduling defaults, reminder send-times, and invoice due-date localization using inferred values. Persist provenance to support audits and future re-computation if better signals arrive.

Acceptance Criteria

Confidence Scoring and Threshold Auto-Apply

Given multiple signals are available (signature tokens, enriched profile location, email headers, phone country code) When the inference engine computes timezone and locale hypotheses Then it assigns a confidence score in the range [0.0, 1.0] to the top hypothesis And if the score >= 0.80 the system auto-applies the inferred IANA timezone and BCP 47 locale to the contact And if the score < 0.80 the system makes no changes and routes the contact to Review with candidate values and scores attached

Signature Token Parsing and Disambiguation

Given an email signature contains timezone indicators (e.g., "PT", "PST", "PDT", "CET", "CEST") or city/region names When the system parses the signature Then recognized indicators are normalized with date-aware DST rules and mapped to a single IANA timezone And ambiguous indicators (e.g., "CST") are not auto-applied unless corroborated by another signal; otherwise they are routed to Review And if timezone is resolved from signature, locale is inferred from the resolved country as a BCP 47 tag unless a stronger locale signal exists

Profile Location Mapping to IANA and BCP 47

Given the enrichment service returns a contact location (city/region/country) with geocodes When the system processes the location Then it maps the location to a single IANA timezone for that locality And it infers a BCP 47 locale using country and known language signal; if none, the country default language is used And this signal contributes to scoring with higher weight than email header offset but lower than explicit signature timezone

Email Header Offset Extraction and Use

Given an email contains one or more Received headers with timestamps and UTC offsets When the system parses the headers Then it extracts the sender-side UTC offset from the earliest hop attributable to the sender And offset-only inference is never auto-applied without corroboration from at least one other signal And when corroborated, the system maps the offset + inferred country to a representative IANA timezone for scoring

Phone Number Country Code Inference

Given a verified E.164 phone number is present for the contact When the system parses the number Then it derives the country from the country code And it infers the locale as the country’s primary BCP 47 language tag unless a stronger locale signal exists And for single-timezone countries it auto-applies the IANA timezone; for multi-timezone countries it contributes to scoring but does not auto-apply without subnational corroboration

Apply Inferred Values to Scheduling, Reminders, and Invoices

Given a contact has auto-applied timezone and locale When a new appointment is created for the contact Then the appointment’s default timezone equals the contact’s IANA timezone And reminder send-times are scheduled at the configured local time in the contact’s timezone And invoices for the contact display and parse dates using the contact’s locale-specific format and localized labels where variants exist

Provenance Persistence and Re-computation

Given inferred timezone and/or locale values are generated for a contact When the system persists the inference Then it stores provenance including sources used, per-signal weights/scores, mapping versions, threshold used, timestamp, and reviewer identity if applicable And when new signals arrive or mapping catalogs are updated Then the engine recomputes; if the new top hypothesis differs and score >= 0.80 it auto-updates and appends an audit record; if score < 0.80 it retains current values and creates a Review task And audit history is queryable per contact with complete change chronology

Review Queue with Confidence Scoring

"As a freelancer, I want to review uncertain contact updates so that bad data doesn’t corrupt my records or trigger wrong reminders."

Description

Introduce a review UI and backend workflow for low-confidence or conflicting fields before committing changes. Show proposed values, source provenance, and diffs vs. existing contact data. Support approve, edit, reject, and merge actions with bulk operations. Notify users when items need review and log decisions for auditability. Feed approved corrections back into parsing heuristics as training hints. Only high-confidence fields auto-apply; medium/low-confidence items await review to protect data quality.

Acceptance Criteria

Auto-Apply High-Confidence Fields Without Review

Given a workspace high-confidence threshold is configured (default 0.90) and a parsed contact contains fields with confidence scores When ingestion completes Then any field with confidence >= threshold is applied to the contact record immediately and does not appear in the review queue And no field with confidence < threshold is auto-applied And fields marked locked/verified on the contact are not overwritten by auto-apply And an Auto-applied audit event is recorded with field, value, score, source, and timestamp

Queue Medium/Low-Confidence Items for Review

Given thresholds are configured (high >= 0.90, medium 0.60–0.89, low < 0.60) and parsing yields fields below the high threshold When ingestion completes Then each field below the high threshold appears as a review item grouped by contact within 60 seconds And duplicate proposals for the same field from the same source are deduplicated And conflicting proposals from different sources are grouped into a single compare-and-choose item

Review UI: Proposed Values, Provenance, and Diffs

Given a contact has existing data and one or more proposed values for fields When a reviewer opens the review item Then the UI shows for each field: existing value vs proposed value side-by-side with inline diff highlighting And displays source provenance (source type, origin link, captured timestamp) and confidence score And displays a link to the related email thread or social profile when available And shows a per-field change preview indicating overwrite, create, or no-change

Single-Item Actions: Approve, Edit, Reject, Merge

Given an open review item When the reviewer clicks Approve Then the selected proposed values are written to the contact and the item is removed from the queue And an audit entry is created with decision=approved and before/after values Given an open review item When the reviewer edits a proposed value and clicks Save Then the edited value is written and recorded as reviewer_edited And the edited value is used for training feedback Given an open review item with conflicting proposals When the reviewer selects Merge Then the reviewer can choose per-field from among proposals or keep existing And the chosen values are persisted in one commit Given an open review item When the reviewer clicks Reject Then no contact data is changed and the item is removed from the queue And a reason can be selected/entered and stored

Bulk Operations and Partial Failure Handling

Given N review items are selected (N <= 500) When the reviewer triggers a bulk Approve, Reject, or Merge Then each item is processed atomically per item with a visible progress indicator And a completion summary shows counts of succeeded, failed, and skipped And failed items remain in the queue with an error message and no partial changes applied And bulk processing throughput is at least 100 items per minute under normal load

Notifications for Pending Review Items

Given new items enter the review queue and the user has review permissions When items are available for review Then the in-app Review badge updates within 60 seconds to reflect the current open count And a daily email digest is sent at 5pm local time if one or more items remain pending And clicking the notification opens the Review Queue filtered to pending items

Auditable Decision Log and Training Feedback Loop

Given any Approve, Edit, Reject, or Merge decision is made When the action is completed Then an immutable audit log entry is stored with reviewer_id, timestamp, field, before_value, after_value, confidence, source, decision, and optional reason And the audit log is retained for at least 1 year and is exportable to CSV Given an Approve or Edit action occurs When the change is saved Then a training hint event is emitted to the parsing heuristics service with field_name, old_value, new_value, source_type, confidence_before, decision_type, and contact metadata And the event is acknowledged by the heuristics service and retried with exponential backoff on transient failure

Privacy, Consent, and Compliance Controls

"As a business owner, I want enrichment to comply with privacy laws and client consent so that I can operate confidently without legal risk."

Description

Embed GDPR/CCPA-compliant processing for enrichment activities. Provide workspace-level controls to enable/disable enrichment, define allowed sources, and honor per-contact opt-outs and “do not enrich” flags. Minimize data collection, encrypt PII in transit/at rest, and maintain processing logs with purposes and retention windows. Support DSAR export/delete and field-level provenance. Enforce robots/ToS compliance, respect do-not-track signals where applicable, and restrict enrichment for sensitive domains or minors. Surface a compliance report per workspace for audits.

Acceptance Criteria

Workspace Enrichment Master Switch and Source Allowlist

Given I am a workspace admin When I toggle Signature Enrich to Disabled Then no enrichment network requests are initiated for any inbound or existing threads And all scheduled enrichment jobs are skipped with reason "enrichment_disabled" in processing logs And a workspace audit log entry records actor, timestamp, and previous/new value Given Signature Enrich is Enabled with an allowlist of sources S When enrichment runs Then only sources in S are queried And calls to disallowed sources are blocked server-side and not persisted And each block is logged with reason "source_not_allowed" Given the allowlist is modified When I save changes Then the change is versioned in audit logs with a diff of added/removed sources And the new rules apply to all new jobs within 1 minute Given enrichment is Disabled When a user attempts a manual enrich on any contact Then the action is not executed and the UI shows "Enrichment is disabled by workspace policy"

Per-Contact Opt-Out and Do-Not-Enrich Enforcement

Given a contact has the Do Not Enrich flag set via UI or API When any enrichment job is created for that contact Then the job is not executed And no network calls are made to enrichment sources And the skip is logged with reason "do_not_enrich" Given a contact previously enriched is set to Do Not Enrich When future emails arrive or a manual enrich is attempted Then existing values remain unchanged by automation And the contact header shows "Enrichment disabled for this contact" Given the Do Not Enrich flag is removed When the next enrichment trigger occurs Then enrichment resumes per current workspace rules

Data Minimization and Field-Level Provenance

Given enrichment is enabled When data is collected Then only the following fields are stored: name, phone, company, timezone, locale, email, profile URL(s) And any additional scraped data is discarded before storage Given any field is enriched or updated When the value is saved Then a field-level provenance record is stored including source identifier, retrieval timestamp, processing purpose, collection method, and retention end date Given a user views a contact When inspecting an enriched field Then the provenance details are visible on demand (hover/click) without exposing unrelated PII Given a retention window is configured for enrichment data When a field’s retention end date is reached Then the field value and its provenance are purged And the purge action is recorded in the audit log with counts

Encryption of PII In Transit and At Rest

Given PII is transmitted between services When inspecting network traffic Then all requests use TLS 1.2+ with strong ciphers And plaintext requests are blocked and logged Given PII is stored in databases or backups When reviewing the storage configuration Then data is encrypted at rest using KMS-managed keys (AES-256 or equivalent) And backups inherit the same encryption Given an unauthorized role attempts to access stored enrichment payloads When the request is made Then access is denied by RBAC And the attempt is logged with user, timestamp, and resource

Processing Logs with Purpose and Retention

Given an enrichment attempt occurs When processing begins and ends Then a processing log entry is created with contact ID, purpose ("contact_enrichment"), source, fields touched, start/end timestamps, outcome (success/skip/fail), and retention end date Given processing logs reach their retention end date When the retention job runs Then expired entries are deleted or anonymized per policy And a deletion summary is recorded in the audit log Given an admin filters or exports processing logs When a CSV or JSON export is requested Then the export contains entries matching the filter And excludes raw PII values while retaining field names and provenance metadata

DSAR Export/Delete and Workspace Compliance Report

Given an admin submits a DSAR export for a contact When the request is processed Then a machine-readable package (JSON and/or CSV) containing the contact’s stored PII, field-level provenance, and processing logs is produced within 15 minutes And the export event is audit-logged Given an admin submits a DSAR delete for a contact When the request is processed Then all stored PII, provenance, and processing logs for that contact are purged within 24 hours except where legal retention is required And the contact is marked Do Not Enrich And a deletion receipt is recorded Given an admin opens the workspace Compliance Report When the report loads Then it displays enrichment enablement state, allowed sources, DNT handling, robots/ToS enforcement status, retention configuration, DSAR counts/statuses, and last audit timestamp And the report can be exported to PDF and JSON

Robots/ToS, Do-Not-Track, and Sensitive Domain/Minor Restrictions

Given a target domain’s robots.txt or meta robots disallows scraping endpoints used for enrichment When an enrichment attempt targets that domain Then no request is made And the job is skipped with reason "robots_disallow" in processing logs Given a source’s Terms of Service disallow automated collection When an admin attempts to add that source to the allowlist Then the system blocks enablement with a compliance warning And records an audit entry if an admin override is used Given an outbound request is made to a site that supports DNT/GPC When the request is sent Then the request includes DNT: 1 and GPC headers And if the site indicates tracking is disallowed, the job is skipped and logged with reason "do_not_track" Given a contact belongs to a restricted domain (e.g., configured blocklist such as .k12/.edu) or has a Minor flag set When enrichment is triggered for that contact Then enrichment is skipped And the skip is logged with reason "restricted_category" And no data is fetched or stored

Admin Field Mapping and Overrides

"As a workspace admin, I want control over how enriched data maps into our contact fields so that automations and invoices use the correct information."

Description

Provide settings for admins to map parsed/enriched fields to SoloPilot’s contact schema and any custom fields. Define field precedence (manual > verified enrichment > signature), lock fields from auto-updates, and configure normalization rules (e.g., phone formatting, title casing). Allow per-field update frequency and TTLs to limit churn. Include test tools to run samples and preview outcomes before applying. Ensure mappings propagate to billing, reminders, and compliance modules consistently.

Acceptance Criteria

Field Mapping to Contact Schema and Custom Fields

Given I am an Admin with Manage Settings permission, When I open Settings > Signature Enrich > Field Mapping, Then I can map each source field (signature.*, enrichment.*) to any standard or custom contact field via typed dropdowns with search. Given I map at least one source to a target, When I save, Then the mapping persists and is versioned with timestamp, user, and diff in the audit log. Given I try to save a mapping where a target has multiple sources and no precedence rule exists for that target, When I save, Then the save is blocked and an inline error lists the targets requiring precedence configuration. Given I map a source to a target with incompatible data type (e.g., array -> string), When I save, Then I receive a blocking validation error naming the offending pair.

Field Precedence Enforcement (Manual > Verified Enrichment > Signature)

Given the default precedence is Manual > Verified Enrichment > Signature and per-field overrides are allowed, When I configure precedence for Job Title to Verified Enrichment > Signature, Then the override is saved and shown in the mapping summary. Given a contact’s Company was set manually, When signature-derived Company arrives, Then the Company field is not updated; the attempt is logged as Skipped with reason "lower precedence". Given a contact’s Phone is sourced from Signature, When a verified enrichment phone arrives, Then the Phone updates to the enrichment value and the source metadata records "verified enrichment", with an audit entry. Given two sources of the same precedence propose different values for the same field in a single run, When processing completes, Then the update is skipped and a conflict event is logged with both candidate values.

Field Locking from Auto-Updates

Given an admin toggles Lock for a target field (e.g., Company), When any non-manual source proposes an update, Then the update is rejected and the field remains unchanged; an audit entry includes source, attempted value, and reason "locked". Given the field is locked, When a human user edits the field manually in the contact profile, Then the manual change is allowed and the source metadata becomes "manual". Given the field is locked and a test run is executed, When viewing the preview, Then the field is highlighted as Locked and shows the proposed-but-suppressed value.

Normalization Rules (Phone E.164, Title Casing, Timezone Canonicalization)

Given Phone normalization is set to E.164 with country fallback from contact locale, When a phone like "(415) 555-1212" and locale "US" is ingested, Then it is stored as "+14155551212"; extensions like "x123" are stored in a separate extension field if mapped. Given Name normalization is set to Title Case, When "joHN van buren" is ingested, Then it is stored as "John van Buren" using exception list for particles. Given Timezone normalization is enabled, When an offset-only value "-0700" or label "PST" is ingested, Then it is converted to a canonical IANA zone "America/Los_Angeles". Given an input fails normalization (e.g., invalid phone), When processing completes, Then the target field is left unchanged and an error is recorded with field, input, and rule.

Per-Field Update Frequency and TTL Controls

Given Update Frequency for Job Title is set to 30 days, When additional updates for Job Title from the same or lower precedence source arrive within 30 days of the last accepted update, Then they are suppressed and logged as "rate-limited". Given TTL for Signature-derived values of Timezone is set to 14 days, When the TTL expires, Then the next qualifying signature value may overwrite older signature-sourced values subject to precedence and locking. Given Update Frequency is set to 0 (no limit) and TTL is set to 0 (no cache), When repeated messages arrive, Then each run evaluates updates without suppression other than precedence/lock rules.

Sample Run and Preview Tool

Given I paste a sample email signature and enrichment JSON and select an existing contact, When I click Run Preview, Then the UI shows per-field Before, Proposed, Normalized value, Source, and Resolution (Applied, Skipped-Locked, Skipped-Precedence, Skipped-Rate-Limited) with no writes performed. Given the preview results, When I click Export, Then a JSON and CSV of the preview rows is downloadable with a unique run ID and timestamp. Given the preview results are satisfactory, When I click Apply Changes, Then only the selected changes are persisted to the chosen contact(s), and an audit entry references the run ID.

Propagation to Billing, Reminders, and Compliance

Given a mapped and normalized Timezone or Locale is updated for a contact, When a reminder is generated after the update, Then the reminder uses the new timezone/locale and is queued within 60 seconds of the contact update. Given Billing relies on Company and Phone fields, When those fields are updated by the mapping engine, Then the next session-to-invoice operation reflects the new values without manual edits; a smoke test generates an invoice draft verifying the values. Given Compliance templates depend on Locale, When Locale changes, Then the appropriate compliance template is selected for subsequent communications; an event is logged showing the template change.

Auto-Form Picker

Chooses and attaches the right intake forms, NDAs, and policy snippets based on keywords, service type, or client segment detected in the thread. Ensures every booking includes what you need for a smooth, compliant first session—without hunting for templates.

Requirements

Conversation & Booking Context Extraction

"As a solo practitioner, I want SoloPilot to infer the service type and client segment from my booking and client messages so that the right forms are picked without manual tagging."

Description

Implement lightweight NLP and deterministic matchers to extract service type, keywords, and client segment from the booking thread, calendar event, and client profile. Normalize detected attributes (e.g., service=“career coaching”, segment=“new client”, keywords=“NDA”, locale=“en-US”) and expose them to downstream selection logic. Ensure privacy-safe processing, multi-language keyword lists, and graceful fallbacks when data is incomplete.

Acceptance Criteria

Cross-Source Attribute Extraction and Normalization

Given a booking thread mentioning "career coaching" and "NDA", a calendar event titled "Intro Career Coaching", and a client profile marked "New Client" When the extractor runs Then it outputs a normalized context with service="career_coaching", segment="new_client", keywords=["nda"], locale="en-US" And all values conform to canonical slugs defined in taxonomy v1.0 (snake_case, lowercase) And duplicates and case variations are deduplicated And the output includes source_attribution per field (thread|event|profile) and a confidence score per field between 0 and 1 And the context object includes extraction_timestamp (ISO-8601 UTC)

Privacy-Safe Processing and Data Minimization

Given context extraction runs for a booking When application logs are inspected Then no raw message content or PII (emails, phone numbers, physical addresses, DOB) is present; only hashed IDs and redacted snippets (e.g., "[REDACTED]") And no new persistent storage of raw thread text is created; transient buffers are cleared within 60 seconds of completion And data in transit uses TLS 1.2+ and logs at rest are encrypted with AES-256 When the account-level setting context_extraction.enabled=false is applied Then the extractor does not run and downstream receives reason="disabled_by_admin" with empty keywords and no service inference

Multi-Language Keyword Detection (en-US and es-ES)

Given client locale=es-ES and thread text "Necesito terapia y firmar un acuerdo de confidencialidad" When extraction runs Then keywords include ["nda"] and service="therapy" is detected using the Spanish keyword list And normalized outputs remain in canonical English slugs while locale="es-ES" is preserved in the context Given locale is missing and content contains Spanish terms When language detection confidence >= 0.7 Then the es-ES keyword list is used; otherwise fallback to en-US And detection precision >= 90% on the provided multilingual test set for top-10 keywords

Deterministic Matchers Override NLP on Exact Matches

Given the thread contains "Service:Executive Coaching" which maps deterministically to service="executive_coaching" And the NLP model suggests service="career_coaching" with higher confidence When extraction resolves the final value Then deterministic mapping prevails and service="executive_coaching" is output with reason="deterministic_match" And if multiple deterministic matches conflict, priority order is thread > calendar_event > client_profile

Graceful Fallbacks With Default Segment and Service

Given no service can be inferred from thread, event, or profile When extraction runs Then service is set to "general_consultation" with confidence=0.0 and warning_code="service_unknown" And segment defaults to "new_client" if the client has no prior paid invoices; otherwise "existing_client" And keywords is [] and processing status="partial" with no thrown errors And downstream receives a valid context object usable by selection logic

Expose Normalized Context to Auto-Form Selection API

Given extraction completes for booking_id=XYZ When the Auto-Form selector requests context Then the API responds 200 with payload matching schema version "context.v1": {service, segment, keywords[], locale, confidence:{...}, source_attribution:{...}, extraction_timestamp} And a system event "context.ready" is published within 1s of completion containing the same payload and an idempotency key so repeated publishes do not create duplicates And when extraction is skipped or partial, the API still returns 200 with reason and defaults applied

Extraction Latency and Resilience

Given average load of 50 requests/min When extraction runs Then p50 latency <= 150ms and p95 latency <= 400ms measured server-side And a hard timeout of 1000ms applies; on timeout, defaults are returned with timeout=true and no exceptions surface to clients And up to 1 retry is attempted on transient errors (HTTP 5xx, timeouts) with exponential backoff starting at 100ms

Form Template Library & Metadata Tagging

"As a practitioner, I want to organize my forms with tags and metadata so that the system can reliably choose the correct template for each booking."

Description

Provide a centralized library to store intake forms, NDAs, and policy snippets with rich metadata (service mappings, client segment, jurisdiction, required/optional, expiry, locale, and version). Support uploads, template variables, previews, and tagging for quick retrieval. Enable soft-delete and restore, and validate templates for missing variables before activation.

Acceptance Criteria

Upload New Template with Type Validation

- Given I am a workspace Admin or Owner in the Template Library, When I upload a supported file (.docx, .pdf, .html, .txt, .md) or create one via the editor, Then the template is saved as Draft with a unique template ID and initial version 1.0.0. - Given I upload an unsupported file type, When I submit the upload, Then the system blocks the upload and displays an error listing the allowed types. - Given the upload succeeds, When I view the template’s details, Then the file name, detected template type, createdBy, and createdAt are recorded and visible.

Metadata Entry and Validation on Save

- Given a Draft template in the editor, When I enter metadata for service mappings, client segment(s), jurisdiction(s), required/optional flag, expiry (date or duration), locale, and version label, Then the system validates required fields and prevents save if any required field is missing, highlighting the field. - Given I save with valid metadata, When I reopen the template, Then the saved metadata values are persisted and retrievable via UI and API. - Given expiry is set to a past date, When I attempt to activate the template, Then activation is blocked with an error that expiry must be in the future.

Template Variable Validation Before Activation

- Given a Draft template containing placeholders in the format {{variable_name}}, When I click Activate, Then the system scans the template and blocks activation if any placeholders are not defined in the workspace variable registry, listing each missing variable. - Given all placeholders are defined, When I click Activate, Then the template status changes to Active and it becomes selectable by the Auto-Form Picker.

Preview Render with Sample Data

- Given a Draft template with placeholders, When I click Preview, Then the system renders a preview with placeholders replaced by sample values or supplied test values without altering the stored template content. - Given a locale is set in metadata, When I preview, Then the preview uses that locale’s formatting for dates and numbers and text direction where applicable. - Given there are unresolved placeholders, When I preview, Then unresolved placeholders are visually highlighted to indicate missing values.

Tagging, Search, and Filter Retrieval

- Given templates exist with metadata and tags, When I search by keyword or filter by service type, client segment, jurisdiction, required/optional, expiry status (active/expired/expiring soon), locale, version status (Active/Draft), or tags, Then results include only templates matching all filters and exclude soft-deleted templates by default. - Given I toggle Include Deleted, When I search, Then soft-deleted templates appear and are clearly marked as Deleted. - Given I change sorting to Updated or Name, When I apply it, Then results reorder accordingly and remain paginated.

Soft-Delete and Restore

- Given I have permission to manage templates, When I soft-delete a template, Then the template moves to a Deleted state with deletedAt and deletedBy recorded and it is no longer selectable by the Auto-Form Picker. - Given a template is soft-deleted, When I restore it, Then it returns to its prior state (Draft or Active) with the same template ID and full version history intact. - Given I choose Permanent Delete on a soft-deleted template, When I confirm, Then the template and all its versions are irreversibly removed and no longer appear in search even when Include Deleted is enabled.

Versioning and Activation Rules

- Given an Active template exists, When I edit it, Then a new Draft version is created (incrementing the version) while the current Active version remains unchanged until I explicitly activate the new version. - Given multiple versions exist for the same template and locale/jurisdiction, When I activate a Draft, Then only one version is Active per locale/jurisdiction and the previously Active version becomes Not Active but remains in version history. - Given a template has an expiry date set in metadata, When the expiry date is reached, Then the template automatically transitions to Expired and is not available for new attachments by the Auto-Form Picker.

Rule-Based Form Selection Engine

"As a practitioner, I want to configure simple rules that map services and client types to forms so that selection is predictable and auditable."

Description

Create a configurable rules engine that maps detected context to required forms. Support condition groups (service, segment, jurisdiction, locale, keywords), precedence, conflict resolution, and default fallbacks. Include a test mode to simulate inputs and preview selected forms. Log rule decisions for troubleshooting and provide safe rollout via draft/publish states.

Acceptance Criteria

Multi-Condition Context Mapping

Given context service_type=SVC_EXEC_COACH, client_segment=SEG_ENTERPRISE, jurisdiction=US-CA, locale=en-US, keywords=["nda","risk"] When the engine evaluates against published rules Then selected_forms == {intake_exec_v2, nda_enterprise, privacy_ca_en, policies_en} and excluded_forms == {} And Then selected_forms has no duplicates and count == 4 And Then evaluation_duration_ms <= 150

Keyword Matching with Thresholds

Given extracted keywords include ["nda", "mutual non-disclosure", "confidential"] When evaluated against keyword rule with synonyms ["nda","non-disclosure","confidentiality"] and match_threshold >= 1 Then form nda_standard is included Given token "nda" appears only as substring in "agenda" When evaluated with whole-word matching enabled Then no keyword match occurs Given keyword appears as "NDA" (mixed case) When evaluated Then match is case-insensitive and form nda_standard is included

Rule Precedence and Exclusive Group Resolution

Given rules R1 precedence=90 adds form nda_standard in exclusive_group=nda and R2 precedence=80 adds form nda_enterprise in exclusive_group=nda When both rules match Then only nda_standard is included, nda_enterprise is excluded, and decision.winner_rule_id == R1 Given rules R3 precedence=70 adds privacy_ca_en (non-exclusive) and R4 precedence=60 adds policies_en (non-exclusive) When both rules match Then both privacy_ca_en and policies_en are included Given two rules in the same exclusive_group tie on precedence When both match Then tie_breaker == most_specific (greater matched conditions) else lowest rule_id wins deterministically

Default Fallback Application

Given no published rules match the input context When evaluated Then selected_forms == default_form_set(workspace) And Then if default_form_set is empty, no forms are attached and a warning log entry is recorded with code=NO_RULES_MATCH severity=warn And Then if any default form is unavailable (archived/missing), it is skipped, an error log entry with code=FORM_NOT_AVAILABLE is recorded, and evaluation succeeds with remaining forms

Draft vs Published Rule Isolation

Given rules R5 state=Draft and R6 state=Published both match When evaluated in live mode Then only R6 contributes to selected_forms Given the same input in test mode with include_drafts=true When evaluated Then R5 and R6 both contribute per precedence and preview is labeled Simulation and no attachments are created Given a rule transitions Draft -> Published When the next evaluation occurs Then the published change takes effect immediately and log.rule_set_version increments by 1

Test Mode Simulation and Preview Output

Given simulated inputs are provided When evaluated in test mode Then the preview displays matched_rule_ids (ordered), selected_forms (ordered by precedence then name), excluded_forms with reasons, and a final_decision_summary And Then no changes occur to bookings/clients/attachments and no notifications are sent And Then the preview is exportable as JSON and CSV and includes a reproducibility_token that replays the same decision

Decision Logging, Auditability, and Idempotency

Given any evaluation occurs When it completes Then a decision log entry is stored with fields {decision_id, timestamp_utc, actor(system|user_id), input_context_hash, rule_set_version, evaluated_rules[{id, matched, reason}], selected_forms[{id, source_rule_id}], excluded_forms[{id, reason}], duration_ms, warnings[], errors[]} And Then logs are queryable by booking_id, client_id, time_range, and rule_id via UI and API And Then repeated evaluations with identical inputs and unchanged published rules produce identical selected_forms order; set_difference(previous, current) == ∅; decision_id is unique; input_context_hash is identical

Auto-Attach & Update Workflow

"As a practitioner, I want forms to auto-attach at booking and stay in sync on changes so that clients always receive the correct paperwork without my intervention."

Description

Automatically attach selected forms to booking confirmations, client portal, and reminders at time of scheduling. Re-evaluate and update attachments on reschedule, service changes, or new context detected. Prevent duplicates, honor required/optional flags, and track per-form completion status. Integrate with notification and reminder systems to nudge clients until completion or deadline.

Acceptance Criteria

Initial Scheduling — Auto-Attach Required Forms

Given a new booking is created for a service with form-mapping rules When the booking is confirmed Then the system attaches all mapped required and optional forms to the booking confirmation email, client portal, and initial reminder And does not attach any form more than once across channels And records an association between the booking, client, form IDs, required/optional flag, and due date And completes within 2 seconds from booking confirmation event And writes an audit log entry with timestamp, rule source, and list of attached form IDs

Reschedule — Re-Evaluate Attachments Without Duplicates

Given an existing booking with attached forms is rescheduled to a different time without service change When the reschedule event is saved Then all previously pending forms remain attached with preserved completion status And reminders are rescheduled to the new timeline relative to the new start time And no duplicate attachments are created And an audit log entry notes reschedule and updated reminder schedule

Service Change — Swap Forms and Preserve Completed Ones

Given an existing booking changes to a different service with a different mapped form set When the change is saved Then forms no longer applicable and not yet completed are detached and marked "removed due to service change" in history And completed forms remain associated and are not requested again And new required and optional forms for the new service are attached And the client is notified of any new or removed form requests And no duplicate attachments are created And the update completes within 3 seconds

New Context Detected in Thread — Update Form Attachments

Given the system detects new keywords or context in the booking conversation that map to additional forms (e.g., NDA) And the context classifier confidence is at or above 0.8 When the context signal is processed Then the corresponding forms are attached to the booking and client portal And the client receives a notification explaining the new request And existing completed forms are not invalidated And duplicates are not created And an audit log records the context trigger, confidence score, and attached form IDs

Completion Tracking and Automated Nudges Until Deadline

Given a form is attached with a due date prior to session start When the form remains incomplete Then the system sends reminders at configured intervals (e.g., 72h, 24h, 2h) until completion or due date And stops sending reminders immediately upon completion And marks the form status as Complete, In Progress, Overdue, or Not Started appropriately And notifies the provider if any required form is Overdue 2 hours before session start And all reminder deliveries are logged with timestamp and channel

Cancellation — Withdraw Pending Forms and Retain Completed Records

Given a booking with attached forms is canceled When the cancellation is saved Then all pending form reminders are canceled And incomplete optional forms are detached from the client portal And incomplete required forms are marked "no longer required due to cancellation" without affecting client compliance metrics And completed forms remain accessible in the client record And an audit log entry records the detachment and reminder cancellations

Consent Capture, Versioning & Audit Trail

"As a practitioner, I want signed forms and their versions stored with an audit trail so that I can prove consent and remain compliant."

Description

Capture signatures and acknowledgments, persist the exact template version sent, timestamps, signer identity signals, and IP/device metadata. Store immutable audit records linked to the booking and client profile, with configurable retention and export for compliance or disputes. Surface status in-session so the practitioner sees whether prerequisites are met before starting.

Acceptance Criteria

Template Version Lock on Consent Submission

Given Auto-Form Picker has sent an intake/consent form for booking X When the client completes and signs the form Then the system stores template_id and template_version used at send time And persists a read-only copy of the rendered document with a SHA-256 checksum And associates the document, version, and checksum to client_id and booking_id And any attempt to alter the stored document or version is rejected and logged

Timestamps and Timezone Normalization

Given server time is synchronized within ±1s of NTP When a consent is sent and later signed Then sent_at and signed_at are recorded in ISO 8601 UTC with millisecond precision And practitioner UI displays times in their configured timezone And clock_skew_ms is recorded if client device time differs by >2s

Signer Identity Signals Captured

Given a client signs via web or mobile When the signature is submitted Then the system records ip_address (IPv4/IPv6), user_agent, device_fingerprint, geo_country/region at sign time And, if authenticated, records user_id and email_verified=true/false And includes these identity signals in the immutable audit record for the consent

Audit Trail Linking and Immutability

Given a booking exists and consent artifacts are generated When viewing the booking or client timeline Then audit events show created_by, sent_at, viewed_at, signed_at, status changes with actor and timestamp And events are append-only and tamper-evident via event_hash and prev_hash And any modification/deletion attempt of past events is blocked and recorded as a security event

In-Session Prerequisite Status Surface

Given I open the live session view for booking X When the service has required consents Then the header shows a status pill per required form: Pending, Viewed, Signed And Start Session is disabled if any required consent is Pending and the workspace setting "block without consent" is enabled And clicking a pill opens consent details including signer identity signals and timestamps

Configurable Retention and Legal Hold

Given workspace consent retention is set to N years When a consent record reaches its retention date Then the system purges PII and stored documents within 24 hours while preserving aggregate counts And if a legal hold exists on the client or booking, deletion is skipped and re-evaluated after hold removal And all retention, deletion, and hold actions are recorded in the audit trail

Export for Compliance or Dispute

Given a user with Role = Owner or Compliance requests an export for booking X or client Y within date range D1–D2 When the export job completes Then a ZIP is produced containing signed PDFs, raw JSON audit records, a metadata CSV, and a SHA-256 manifest And the download link requires authentication and expires after 7 days And file checksums in the manifest match stored values and counts equal the audit trail records

Admin Override & Manual Adjustments UI

"As a practitioner, I want to quickly review and override suggested forms so that I maintain control when special cases arise."

Description

Provide a pre-send review panel to view suggested forms, add/remove items, toggle required/optional, reorder, and save the adjustments as a reusable rule. Show inline warnings for potential compliance gaps and allow one-time overrides without altering global rules. Ensure fast, keyboard-friendly interactions to minimize friction in busy scheduling flows.

Acceptance Criteria

Pre-Send Review Panel Core Actions

Given a booking with detected forms, when the user opens the Review Panel, then the panel loads within 300ms (P95) and lists all suggested items with type, required/optional state, and source (rule or detection). Given the panel is open, when the user removes an item via keyboard Delete or click, then the item is removed and an Undo toast appears for 5 seconds. Given the panel is open, when the user toggles required/optional via Space or click, then the state updates, the badge changes, and validation reflects the new requirement immediately. Given the panel is open, when the user reorders items via keyboard (Alt+Arrow) or drag-and-drop, then the new order persists and is reflected in the send preview. Given the panel is open, when the user searches templates by keyword and presses Enter, then matching forms/NDAs/policy snippets appear within 150ms (P95) and the highlighted item is added. Given changes are made, when the user clicks Send, then the final attachment list matches the panel state exactly.

Save Adjustments as Reusable Rule

Given customized attachments and available metadata (service type, keywords, client segment), when the user selects Save as Rule and names the rule, then a new rule is created with the current configuration and conditions. Given the new rule is saved, when an eligible booking matches its conditions, then the Auto-Form Picker applies the rule automatically and flags the source as "Rule: <name>" in the panel. Given rule saving, when the user opts Save for future only (default), then no existing global defaults are altered. Given conflicting rules exist, when a conflict occurs, then the user is prompted to resolve priority and the selected priority is persisted. Given audit requirements, when a rule is saved or edited, then createdBy, createdAt, version, and changeNote are recorded and viewable from Rule details.

One-Time Override Without Altering Global Rules

Given the panel shows suggestions derived from rules, when the user enables One-time Override, then changes apply only to the current send and are not persisted to any rule or default. Given an override is used, when the booking is finalized, then no new rule is created and global rule statistics remain unchanged. Given compliance, when an override introduces a Blocking compliance gap, then Send is disabled until the gap is resolved or an allowed exception flow is completed with a required justification note (max 300 characters). Given audit, when an override occurs, then an entry is logged with user, timestamp, items changed, and justification.

Inline Compliance Warnings and Resolution

Given detection rules identify potential gaps, when the panel renders, then warnings appear inline next to affected items with severity (Info/Warning/Blocking) and rationale text. Given a warning is shown, when the user clicks Learn more, then a policy link opens in a new tab. Given a Warning severity, when the user adds the suggested item, then the warning resolves immediately without a full reload. Given a Blocking severity, when the user attempts Send, then Send is prevented and an actionable checklist is displayed; upon satisfying all items, Send is enabled. Given state changes, when items are added/removed/toggled, then warnings recalculate within 100ms.

Keyboard-First Accessibility

Given the panel is focused, when the user navigates via Tab/Shift+Tab, then focus order follows visual order and is trapped within the modal until closed. Given screen reader users, when the panel opens, then it announces title, count of items, and instruction text via ARIA and meets WCAG 2.1 AA for name/role/value with no accessibility violations. Given keyboard operations, when the user presses shortcuts (A=Add, R=Toggle required, D=Remove, Alt+Arrow=Reorder, Ctrl+S=Save as Rule, Enter=Send), then actions execute and a visible shortcut hint is available. Given contrast requirements, when the panel is displayed, then actionable elements meet 4.5:1 contrast and have a minimum 44x44px target size.

Performance and Reliability

Given normal network conditions, when opening the panel, then time-to-interactive is ≤300ms (P95); search results appear ≤150ms (P95); reordering latency is ≤50ms (P95); Send confirmation appears ≤500ms (P95). Given autosave, when any change is made, then the state is autosaved locally within 100ms and recoverable after a soft refresh or crash. Given transient API failures, when save-as-rule or search fails, then a retry with exponential backoff is attempted up to 3 times and the user sees a non-blocking error with a retry option. Given offline mode, when the panel is opened offline, then local operations (reorder, toggle, remove) remain usable and changes sync within 5 seconds after connectivity resumes.

Nudge Sequencer

If there’s no response, sends branded, polite follow-ups with refreshed availability across the same channel (email/SMS/DM) at smart intervals. Converts more inquiries into scheduled sessions while you stay hands-off.

Requirements

Smart Interval Engine

"As a solo practitioner, I want nudges to be sent at intelligent times on the same channel so that recipients are more likely to notice and respond without me managing timing."

Description

Determines follow-up send times using configurable cadences and channel-aware heuristics (email/SMS/DM) that consider recipient timezone, sender business hours, last interaction timestamp, and response likelihood. Supports per-sequence rules (e.g., 1 hour, 1 day, 3 days), throttling, skip-weekend options, and guardrails to prevent over-messaging. Integrates with SoloPilot contact activity and scheduler signals to avoid sending near an active booking flow. Centralizes scheduling logic so other modules can query next-send time. Produces an auditable schedule and allows per-contact snooze/skip.

Acceptance Criteria

Per-Sequence Cadence Scheduling With Timezone and Business Hours

Given a sequence with step offsets [1h, 1d, 3d] and a contact in timezone TZ And sender business hours and channel windows are configured And the channel for the next step is Email When the last interaction timestamp is T Then next_send_at is the earliest time ≥ (T + 1h) that falls within both the recipient local allowed window and sender business hours And the scheduled step_id equals the first pending step in the sequence And next_send_at is in the future and persisted as ISO 8601 UTC with contact_id, sequence_id, step_id, and channel

Channel Windows and Weekend Skip Enforcement

Given configured allowed delivery windows for the channel and a skip_weekends flag And a computed next_send_at that may fall outside these constraints When the engine finalizes the schedule Then if next_send_at is outside the allowed window, it is shifted to the start of the next allowed window in the recipient's local time And if skip_weekends is true and next_send_at falls on Saturday or Sunday, it is shifted to the next Monday at the start of the allowed window And an adjustment reason_code is recorded as outside_channel_window or weekend_skipped as applicable And boundary handling is inclusive of window_start and exclusive of window_end And no sends occur during disallowed periods

Throttling and Over-Messaging Guardrails

Given configured limits max_per_24h, max_per_7d, and min_interval_between_sends across all channels for a contact When scheduling a follow-up would breach any limit Then the send is suppressed and next_send_at is moved to the earliest time that satisfies all limits And reason_code = throttled is recorded with the breached limit And no more than one nudge is scheduled for the contact at the same minute across channels And suppression and reschedule are persisted atomically

Booking-Flow Awareness Suppresses Sends

Given contact activity or scheduler signals within the configured booking_silence_window (booking_link_opened, slot_selected, checkout_started, payment_initiated) When computing next_send_at Then the send is suppressed and rescheduled to the end of the booking_silence_window And reason_code = booking_flow_active is recorded And if a booking is confirmed before next_send_at, the pending send is canceled and marked as superseded_by_booking And no sends occur while booking_flow_active is true

Centralized Next-Send Time API Contract

Given a valid contact_id and sequence_id When the NextSendTime API is queried Then the response includes next_send_at (ISO 8601 UTC), channel, step_id, rule_id, reason_code, and correlates to the persisted schedule And repeated queries without state changes return identical values (idempotent) And if no future send is possible, next_send_at is null and reason_code ∈ {completed, throttled, booking_flow_active, snoozed, skipped, canceled} And validation errors return structured error codes and do not mutate state

Auditable Schedule and Decision Log

Given any schedule create, update, suppress, reschedule, cancel, snooze, or skip action When the action is committed Then an immutable audit entry is recorded with timestamp (UTC), actor (system|user), contact_id, sequence_id, step_id, channel, prior_value, new_value, reason_code, and inputs_snapshot (last_interaction_at, recipient_timezone, business_hours, channel_window, limits) And audit entries are queryable by contact_id, sequence_id, and date range And audit export returns CSV and JSON with the recorded fields exactly as stored

Per-Contact Snooze and Skip Controls

Given a contact with an active sequence When snooze_until = S is applied Then no sends occur before S and next_send_at is recomputed at S respecting cadence, windows, and limits And an audit entry is recorded with reason_code = snoozed When skip_next = true is applied Then the next scheduled step is canceled, the following step is scheduled per cadence, and an audit entry is recorded with reason_code = skipped And UI and API state reflect the current snooze/skip status and next_send_at

Same-Channel Thread Continuity

"As a coach, I want nudges to continue in the existing conversation on the original channel so that they feel natural and not like a new outreach."

Description

Sends all follow-ups over the original inquiry channel and preserves conversation threading. For email, sets proper headers (Message-ID, In-Reply-To, References) to keep messages in the same thread; for SMS, uses the same long code/short code; for supported DMs, reuses the original conversation ID. Handles channel-specific rate limits and message size constraints while rendering content appropriately per channel. Stores and reuses per-contact channel metadata and gracefully handles provider errors with within-channel retries. Ensures recipients perceive nudges as a natural continuation rather than a new outreach.

Acceptance Criteria

Email Threading via Headers

Given an original inquiry email is stored with its Message-ID and Subject When the Nudge Sequencer sends a follow-up via email Then the outgoing email includes In-Reply-To and References headers that contain the original Message-ID And the outgoing email has a unique Message-ID And the Subject preserves the original subject text with an appropriate "Re:" prefix (no new subject lines) And From and Reply-To match the configured mailbox used for the original reply And delivery to seeded Gmail and Outlook test inboxes groups the follow-up inside the same thread/conversation as the original within 2 minutes

SMS Continuity via Same Sender ID

Given the original inquiry and prior nudges to a contact were sent via SMS from a specific long code/short code/alphanumeric sender When subsequent follow-ups are sent via SMS Then all follow-ups to that contact are sent using the same sender ID And delivery receipts for each follow-up confirm the same sender ID used previously And if the sender ID is temporarily unavailable, the send is retried (up to 3 attempts with backoff) rather than switching sender IDs And if after retries the sender ID remains unavailable, the attempt is marked Failed and no alternate sender/channel is used

DM Conversation ID Reuse

Given an original inquiry occurred over a supported DM platform with a stored conversationId/threadId When the Nudge Sequencer sends a follow-up over that DM platform Then the API call targets the same conversationId/threadId And if the conversationId is expired or invalid, the system re-opens or rehydrates the thread within the same platform and prefixes the first message with "Following up on our chat on {date}" for context And no cross-channel fallback is attempted And audit logs record both the prior conversationId and the successfully used conversation/thread identifier

Per-Contact Channel Metadata Persistence

Given a contact has prior outreach metadata (channel type, email message-id, SMS sender ID, DM conversationId) When scheduling and sending a follow-up Then the system reads the contact’s channel metadata with p95 latency ≤ 100 ms And the same metadata is reused consistently across retries so the follow-up remains in-thread And upon successful provider acknowledgment, the follow-up’s provider message identifier is stored and linked to the contact and thread And if required metadata is missing, the send is blocked with an actionable error (no message is sent) And metadata persists across service restarts and deployments

Channel-Specific Size and Rendering Constraints

Given channel-specific limits and rendering rules are configured When composing follow-ups Then email messages are sent as multipart/alternative (text/plain + text/html) in UTF-8 and total size ≤ 100 KB And SMS messages exceeding 1 segment are auto-truncated to a maximum of 3 segments (or 306 GSM-7 characters / 201 UCS-2) with an appended short link; content beyond the limit is omitted And DM messages are validated against the platform’s max length and truncated with a short link if necessary And messages that violate size limits are not sent; they are corrected or blocked with clear reasons logged

Provider Error Handling and Within-Channel Retries

Given a transient provider error occurs (HTTP 5xx, timeout, or explicit retryable code) When sending a follow-up on a channel Then the system retries within the same channel using jittered exponential backoff (min 2s, max 5m) up to 3 attempts And an idempotency key ensures no duplicate messages are produced by retries And on permanent errors (HTTP 4xx non-rate-limit), retries stop and the attempt is marked Failed with surfaced error details And all attempts and outcomes are recorded in the send log

Channel Rate Limit Compliance and Backoff

Given provider and workspace rate limits are configured per channel When the Nudge Sequencer sends follow-ups at scale Then per-sender/per-workspace token buckets ensure sends do not exceed configured limits (e.g., 1 SMS/sec per long code; provider-specific defaults) And if a rate-limit response is encountered, messages are queued and retried with backoff within the same channel rather than dropped or cross-channeled And staging load tests of ≥ 1,000 messages complete with zero provider 429/RateLimitExceeded errors and ≥ 95% throughput utilization of configured limits

Branded Templates & Personalization

"As a consultant, I want my follow-ups to match my brand and include personalized details so that nudges feel professional and increase conversions."

Description

Provides a template editor to create polite, on-brand follow-up messages with voice presets, signatures, and assets. Supports merge fields (e.g., first name, service, last message snippet, last contact date) with validation and safe fallbacks. Enables per-channel variants (email/SMS/DM) and previews with test sends. Includes a library of recommended templates tuned for conversion, with the option to A/B test subject lines and phrasing. Automatically injects contextual details such as booking links and session info while maintaining brand consistency.

Acceptance Criteria

Template Creation with Voice Preset and Signature

Given I am in the Template Editor with at least one voice preset and signature configured, When I create a new template with a unique name, select a voice preset and a signature, and click Save, Then the template saves successfully with the selected preset and signature and is retrievable on reload. Given I attempt to save a template without a name, When I click Save, Then a validation error "Template name is required" is shown and the template is not saved. Given I edit the template name and signature, When I click Save, Then the changes are persisted and reflected in previews. Given I duplicate an existing template, When I save the duplicate, Then a new template with a unique ID and a "Copy" suffix in the name is created.

Merge Fields Validation and Safe Fallbacks

Given the editor contains merge fields {{first_name}}, {{service}}, {{last_message_snippet}}, and {{last_contact_date}}, When I click Validate, Then recognized fields are marked valid and any unknown placeholders are highlighted with an error. Given the template contains an unknown merge field {{foo}}, When I attempt to save, Then save is blocked with an error listing the unknown fields. Given the recipient record lacks first_name, When I preview or test-send a template with {{first_name|fallback="there"}}, Then the rendered message shows "there" and no raw placeholder. Given the recipient record lacks last_message_snippet, When I preview or test-send without an explicit fallback, Then the system uses the safe default "(previous message unavailable)" and no raw placeholder appears. Given I insert a merge field from the picker, When I select "Service", Then the placeholder {{service}} is inserted at the cursor.

Per-Channel Variants (Email/SMS/DM) with Channel Rules

Given I open a template, When I add an Email variant with Subject and Body, an SMS variant with Body only, and a DM variant with Body only, Then the template saves with all three channel variants under a single template ID. Given the SMS variant exceeds 320 GSM-7 characters, When I attempt to save, Then I am warned that the message will send as multiple segments and I can still save. Given the SMS or DM variant includes HTML tags, When I validate, Then an error is shown and save is blocked until tags are removed. Given the Email variant lacks a Subject, When I attempt to save, Then save is blocked with "Subject is required for email". Given I switch channels in the editor, When I preview each variant, Then channel-specific formatting and limits are applied and displayed.

Previews and Test Sends per Channel

Given I have a template with channel variants, When I click Preview for Email/SMS/DM, Then the preview renders the selected channel with merge fields resolved against a chosen contact. Given I trigger a Test Send to my own contact details for each channel, When the send completes, Then a success toast with timestamp is shown and an entry is logged in the template's test history. Given the test contact is missing a required delivery endpoint (e.g., no mobile for SMS), When I click Test Send for SMS, Then the action is blocked with a clear error. Given my email branding assets are configured, When I preview an email, Then the brand logo, colors, and signature render according to my brand settings.

Recommended Library Templates and A/B Testing

Given I open the Template Library, When I insert a recommended "Polite Follow-up" template into my workspace, Then the template loads into the editor with placeholders intact and can be saved without errors. Given I enable A/B testing for an email template, When I create Subject A and Subject B and set a 50/50 split, Then both subjects are saved and appear in preview toggles. Given A/B is enabled, When the sequencer sends follow-ups using this template, Then each send is assigned either variant A or B and the assignment is recorded for reporting. Given A/B is disabled, When I save the template, Then only a single subject/body is retained and used.

Automatic Injection of Booking Link and Session Context with Brand Consistency

Given the contact is associated to a service with an active booking link, When I preview or test-send any channel, Then the booking link is automatically injected at the designated placeholder or appended to the footer if no placeholder exists. Given no booking link is available for the selected service, When I preview or test-send, Then the system uses the account default booking link; if none exists, a warning is displayed and no broken link appears. Given the session date/time and service name are available, When I preview or test-send, Then those details are injected into {{service}} and {{session_datetime}} using the account's locale and time zone. Given brand colors, logo, and signature are configured, When the system injects contextual details, Then brand styling remains consistent across email previews and does not alter SMS/DM beyond plain-text content.

Availability Sync at Send-Time

"As a therapist, I want each follow-up to include my current openings so that clients can book immediately without back-and-forth."

Description

Fetches real-time availability from SoloPilot Scheduler at the exact send moment to include accurate openings and a one-click booking link. Selects time slots that match the intended service duration, recipient timezone, and provider preferences, inserting top options inline (e.g., next 3 slots) and updating copy if slots shift. Handles slot expiration and calendar updates between scheduling and sending, falling back to a general booking link or waitlist when no times are available. Shortens links per channel and tracks click-through for conversion analytics.

Acceptance Criteria

Real-Time Availability Fetch at Send-Time

Given a nudge is due to send for a specific service and provider When the message enters the dispatch phase (≤2 seconds before send time) Then the system requests current availability from SoloPilot Scheduler using serviceId, providerId, recipientTimezone, and serviceDuration And selects the next 3 earliest bookable slots strictly after the current time And inserts those slots inline with human-readable times and one-click booking links per slot in the outbound message

Recipient Timezone Alignment and Display

Given the recipient has a stored timezone When formatting inline time options Then the times are converted to the recipient’s timezone and include a timezone abbreviation (e.g., PT) And if the recipient timezone is unknown, fallback to the provider’s timezone and label it accordingly And the displayed times account for any DST changes on the slot date

Service Duration and Provider Preferences Compliance

Given a service has a defined duration and the provider has buffer, working hours, blackout dates, external calendar sync, and daily cap preferences When retrieving and filtering availability Then every returned slot satisfies the service duration plus required buffers And occurs within provider working hours and not on blackout dates And does not overlap external calendar busy times And does not exceed the provider’s daily session cap

Slot Changes Between Queueing and Send-Time

Given candidate slots may have changed since the nudge was scheduled When building the message at send-time Then the system regenerates the inline options from current availability And replaces any stale slots with the latest next up to 3 eligible slots And updates the message copy to reflect the final slots actually sent And if fewer than 3 slots are available, only the available number are shown

No Availability Fallback to Booking or Waitlist

Given no eligible slots are returned for the provider’s booking horizon When generating the message at send-time Then the system omits inline time options And includes a single prominent general booking link And if a waitlist is enabled for the service, includes a waitlist link instead of the general booking link And the message copy updates to invite booking via the provided link

Channel-Specific Link Shortening and Click Tracking

Given the outbound channel is email, SMS, or DM When generating booking URLs (inline options and fallback) Then the system shortens links using the configured shortener for that channel And appends unique tracking parameters (messageId, recipientId, channel, serviceId, slotId when applicable) And records a click-through analytics event upon link resolution with the associated metadata And shortened links resolve to the correct deep link destination

Resilience to Scheduler Errors at Send-Time

Given the SoloPilot Scheduler API is unavailable, returns 4xx/5xx, or times out When attempting to fetch availability at send-time Then the system retries up to 2 times with exponential backoff within 1 second total And if still unsuccessful, sends the message without inline slots and includes the general booking link And logs the error with correlation IDs and marks the message with a recoverable degrade flag And no duplicate sends are triggered by the retry logic

Reply/Booking Detection & Auto-Stop

"As a freelancer, I want sequences to stop the moment someone replies or books so that I don’t annoy clients and look automated."

Description

Monitors incoming replies across email, SMS, and supported DMs, along with SoloPilot booking events, to immediately pause or stop the sequence and prevent additional nudges. Deduplicates signals (e.g., reply and booking within minutes), updates contact status, and records the outcome with timestamps. Optionally sends a polite confirmation or thank-you message and opens a task for the provider if manual follow-up is needed. Supports manual override, sequence resume, and granular logging for troubleshooting.

Acceptance Criteria

Immediate Pause on Reply (Same Channel)

Given a contact has an active nudge sequence on channel X with at least one pending nudge When a reply is received on the same channel/thread for that contact Then pause the sequence within 15 seconds And cancel all pending nudges for that sequence And prevent any further sends until explicitly resumed And set the contact sequence status to "Replied" And persist detection details (channel, message_id, detected_at UTC)

Stop on Booking Event with Deduplication

Given a contact has an active nudge sequence When a SoloPilot booking is created for that contact (new or rescheduled) Then stop the sequence within 15 seconds And cancel all pending nudges And set the contact sequence status to "Booked" And persist booking details (booking_id, start_time, detected_at UTC) Given a reply and a booking occur within a 10-minute window When outcomes are recorded Then record a single final outcome of "Booked" And mark the reply signal as deduplicated with dedup_reason "superseded_by_booking" And ensure only one confirmation and/or task is triggered

Cross-Channel Reply Detection & Global Stop

Given a contact has active sequences on any supported channels (email, SMS, DM) When a reply is received on any mapped channel for that contact Then stop or pause all active sequences for that contact within 15 seconds And set the originating channel on the outcome to the reply channel And ensure no further nudges are sent across channels until explicitly resumed

Outcome Logging & Timeline Visibility

Given any stop/pause trigger (reply, booking, manual action) When the outcome is recorded Then create an immutable outcome record with fields: contact_id, sequence_id, trigger_type, channel, source_ids (message_id or booking_id), detected_at (UTC ISO 8601), actor_id (system or user), dedup_key And publish the outcome to the contact timeline within 60 seconds And expose the outcome via the Outcomes API endpoint And display a human-readable entry in the UI timeline reflecting the trigger and status change

Post-Stop Actions: Confirmation Message and Task Creation

Given workspace setting "Auto-confirmation on stop" is enabled When a sequence is paused or stopped due to a reply or booking Then send one brand-compliant confirmation/thank-you on the originating channel within 60 seconds And include appointment details for bookings And do not send if a confirmation was sent in the last 24 hours for the same contact and sequence Given a reply is classified as "Needs manual follow-up" by rules or ML When the sequence stops Then create one task assigned to the provider within 30 seconds with link to the contact, reply snippet, and due_at SLA (default 24h) And prevent duplicate tasks for the same conversation within a 24-hour window

Manual Override and Sequence Resume

Given a sequence was auto-paused or auto-stopped When a user with appropriate permissions clicks "Resume sequence" in the UI Then schedule the next pending nudge according to sequence rules within 60 seconds And log a manual action record with actor_id, action="resume", and timestamp (UTC) And update the sequence status to "Active" Given a sequence is active When a user applies an "Ignore replies for N hours" override Then the system will not auto-stop due to replies during the override window And log detection events during the window as "ignored_by_override" without affecting sends

Granular Troubleshooting Logs and Error Handling

Given a detection or stop event is processed When logging is performed Then write a debug log entry including detection_rule_id, channel, message_id or booking_id, thread identifiers, normalization steps taken, dedup decision, and processing latency And retain debug logs for at least 30 days And make logs queryable via an admin-only log viewer with filter by contact_id, sequence_id, and time range Given an external provider error or rate limit occurs during detection or stop actions When retry policy is applied Then retry up to 3 times with exponential backoff And surface a final failure alert in the admin console if retries exhaust And fail safe by preventing further nudges until the issue is resolved or a manual resume is performed

Compliance, Opt-Outs, and Quiet Hours

"As a business owner, I want nudges to follow legal and ethical sending rules so that I protect my brand and avoid penalties."

Description

Enforces per-contact consent and channel-level preferences, honoring opt-out keywords (e.g., STOP) and unsubscribe links. Applies quiet hours by recipient timezone and respects regional regulations (e.g., TCPA for SMS, GDPR data handling), with configurable send windows and suppression lists. Maintains immutable audit logs for sends, replies, and opt-out events, and performs bounce/blocked number handling with automatic suppression. Provides admin controls to configure compliance defaults per workspace.

Acceptance Criteria

Per-Contact Consent Enforcement by Channel

- Given a contact has no recorded consent for SMS and the sequence step targets SMS, When the send is evaluated, Then the SMS is not sent, the event is logged as "blocked - no consent", and any configured channel fallback is attempted within the same evaluation cycle. - Given a contact has consent for email but not SMS, When a multichannel step is evaluated, Then only email is sent and SMS is suppressed. - Given a contact's consent state is updated to "revoked" for a channel, When any pending or future steps are evaluated, Then that channel is suppressed within 60 seconds and suppression is reflected in the contact's preferences. - Given a consent record exists for a contact and channel, When viewed, Then it displays channel, lawful basis (if applicable), timestamp, source, and IP (if collected).

Channel-Specific Opt-Out Processing (SMS STOP and Email Unsubscribe)

- Given an inbound SMS containing STOP, STOPALL, UNSUBSCRIBE, or CANCEL (case-insensitive, trimmed), When received, Then mark the SMS channel opted-out for that contact within 5 seconds, log the event, and suppress all future SMS sends from sequences. - Given a contact clicks a unique unsubscribe link in an email and selects "Unsubscribe from email", When submitted, Then the email channel is suppressed within 60 seconds, a confirmation page is shown, and the event is logged with IP and user agent. - Given a contact previously opted out of SMS, When they send START, UNSTOP, or YES, Then require an explicit confirmation reply "YES" to re-opt-in; upon confirmation, lift suppression and log the re-opt-in with timestamp. - Given an unsubscribe link is accessed with an invalid or expired token, When the link is visited, Then no changes are made and a secure option to request a fresh link is presented and logged.

Quiet Hours by Recipient Timezone

- Given quiet hours are configured as 20:00–08:00 local time for SMS and email, When a sequence step becomes due at 21:30 in the recipient's timezone, Then the send is deferred to the next available window starting 08:00 local time, preserving message order. - Given a contact's timezone is unknown, When evaluating quiet hours, Then the system uses the workspace default timezone and logs the fallback. - Given a message is deferred due to quiet hours, When the send window opens, Then the message is dispatched within 0–10 minutes randomized delay and the deferral is recorded in the audit log. - Given an admin updates quiet hours, When evaluation runs next, Then new windows take effect for all future evaluations within 5 minutes.

Regional Compliance Rules Application (TCPA/GDPR)

- Given an SMS to a US phone number is promotional and prior express written consent is not recorded, When the send is evaluated, Then the SMS is blocked, logged as "blocked - TCPA consent missing", and the sequence proceeds per fallback rules without sending SMS. - Given a contact is flagged as EU/UK resident, When processing their data for messaging, Then a lawful basis is required and stored in the consent record before any sends are allowed. - Given an admin executes a GDPR erasure request on a contact, When processed, Then PII is deleted from operational systems, audit logs retain immutable event metadata with pseudonymized identifiers, and a completion receipt is logged within 72 hours. - Given regional configuration is ambiguous, When evaluating compliance, Then the stricter rule applies by default and the decision is logged.

Bounce and Blocked Number Handling with Auto-Suppression

- Given an email returns a hard bounce from the provider, When the bounce webhook is received, Then the email channel for that contact is immediately suppressed, the bounce reason and code are logged, and no further emails are sent from sequences. - Given an SMS provider returns "unknown subscriber" or "blocked" for a send attempt, When the delivery receipt is received, Then the SMS channel is suppressed for that contact and the error code is logged. - Given a soft bounce (e.g., mailbox full or temporary failure) is received, When retry policy is applied, Then up to 3 retries occur over 24 hours with exponential backoff; after final failure, the channel is paused for 24 hours and the event is logged. - Given a suppressed channel is manually reactivated by an admin, When reactivation occurs, Then the action requires an entered reason, is logged, and previously suppressed messages are not retroactively sent.

Immutable Audit Logs for Messaging and Compliance Events

- Given any outbound message, inbound reply, opt-in/out change, suppression, consent change, or compliance block, When the event occurs, Then an audit log entry is appended with UTC timestamp, contact id, channel, actor (system/user), provider ids, region, and decision. - Given audit logs, When a user attempts to edit or delete an entry, Then the action is denied, an error is shown, and the attempt is itself logged. - Given new logs are written, When persisted, Then entries are tamper-evident via cryptographic hash chaining across records and verifiable via an integrity check endpoint. - Given an admin queries logs, When filters (contact, channel, date range, event type) are applied, Then results return within 5 seconds for up to 10,000 records and can be exported as CSV or JSON subject to role-based access controls.

Admin Controls for Compliance Defaults per Workspace

- Given a workspace admin, When accessing Compliance Settings, Then they can configure per-channel consent requirements, quiet hour windows, unsubscribe footer content, opt-out keyword behavior, retry policies, and regional rule strictness. - Given settings are updated, When saved, Then changes apply to all future evaluations within 5 minutes and are versioned with who/what/when in audit logs. - Given a new workspace is created, When defaults are not customized, Then safe defaults are applied: email unsubscribe required, SMS TCPA strict mode, quiet hours 20:00–08:00, and strict regional fallback. - Given role-based access controls, When a non-admin attempts to change compliance settings, Then access is denied and the attempt is logged.

Sequence Builder & Performance Analytics

"As a solo operator, I want to design sequences and see what works so that I can improve conversions over time."

Description

Offers a visual builder to create, edit, clone, and assign nudge sequences to inquiry sources or pipelines. Configures per-step timing, content, and stop rules with preview of channel-specific rendering. Provides analytics by sequence and step, including send/deliver/open/click/reply/book rates and time-to-book, with filters by channel, service, and cohort. Supports exporting metrics, surfacing optimization suggestions (e.g., adjust step-2 delay), and A/B testing for copy and timing to iteratively improve conversion.

Acceptance Criteria

Visual Builder: Create, Edit, Clone, Assign Sequences

Given I have editor permissions, When I open the Nudge Sequencer visual builder and create a new sequence, Then I can add, reorder, and delete steps via drag-and-drop. Given I configure a step, When I set timing, Then I can choose delay units (minutes/hours/days/weeks) relative to trigger or previous step and optionally restrict to business hours. Given I edit step content, When I select a channel (email/SMS/DM), Then channel-specific editors and variables are available and validation enforces channel constraints. Given I define stop rules, When a reply is detected or a booking is created, Then the sequence stops for that contact and the stop reason is logged. Given I save the sequence, When I publish it, Then a new immutable version is created and the status changes from Draft to Active. Given an existing sequence, When I clone it, Then all steps and settings are duplicated and performance data is excluded. Given pipelines or inquiry sources exist, When I assign the sequence to one, Then new inquiries from that source/pipeline auto-enroll in the Active version. Given I preview the sequence, When I choose a sample contact, Then variables resolve with sample data and channel formatting is shown.

Channel-Specific Rendering Preview

Given I select Email preview, When I toggle Desktop/Mobile, Then layout, subject, preheader, link tracking, and branding render as sent. Given I select SMS preview, When content exceeds one segment, Then the system shows estimated segments and carrier-safe character count. Given I select DM preview, When platform limitations apply (e.g., no clickable links), Then the preview reflects those constraints and displays a non-blocking warning. Given I insert dynamic variables, When a variable may be missing, Then the preview shows fallback values and validation blocks publish until a fallback is provided. Given I send a test message, When I specify a test recipient, Then the message delivers via the selected channel and is logged in test activity with timestamp and status.

Stop Rules and Auto-Halt on Reply/Booking

Given a sequence with stop rules enabled, When a recipient replies via any enrolled channel, Then all remaining steps are canceled for that recipient within 1 minute and the stop reason is recorded as Reply. Given a booking event is created for the recipient that matches the targeted service, When the event is detected, Then the sequence cancels and logs Booked as the stop reason. Given a step hard-bounces or fails on a channel, When a fallback channel is configured, Then the next step sends via the fallback channel and the failure is logged. Given a per-step stop rule is set to stop on link click, When the recipient clicks the tracked link, Then downstream steps are canceled. Given a manual pause is applied to a contact, When the sequence is paused, Then no steps send during the pause window and the schedule resumes after the pause ends.

Analytics by Sequence and Step with Filters

Given at least 30 days of activity exist, When I open Analytics, Then I can switch between By Sequence and By Step views. Given the analytics view, When I apply filters for channel, service, cohort, and date range, Then counts and rates recalculate within 2 seconds and show sample size n. Given metrics display, Then each sequence/step shows sends, delivered, open rate (opens/delivered), click rate (clicks/delivered), reply rate (replies/delivered), book rate (bookings/unique recipients), and median time-to-book (with 95% CI). Given I click a metric, When I drill down, Then I see contributing records with timestamps, channel, and identifiers. Given workspace time zone is adjusted, When I change time zone, Then analytics rebase to the selected time zone consistently across UI and exports.

Metrics Export with Date Range and Filters

Given filters and a date range are selected, When I export CSV, Then the file includes one row per sequence/step with columns: sequence_id, sequence_name, version, step_number, channel, sends, delivered, opens, clicks, replies, bookings, open_rate, click_rate, reply_rate, book_rate, ttb_median_seconds, ttb_mean_seconds, cohort, service, start_date, end_date, timezone. Given the export completes, Then row counts and metric totals match the UI within ±0.1% and the file is UTF-8 with headers. Given the dataset exceeds 100k rows, When I request export, Then I receive a downloadable link via email that expires in 7 days and the export event is audit-logged with user, timestamp, filters, and file size. Given I re-run an export with identical filters and window, When no new data has arrived, Then a cached export is delivered and labeled as Cached with its generation timestamp.

Optimization Suggestions Surface and Actions

Given a step has ≥200 deliveries in the last 30 days, When its metric underperforms the workspace benchmark by ≥15%, Then the system surfaces a suggestion with rationale and a recommended change (e.g., increase delay from 12h to 24h). Given a suggestion is shown, When I click Apply, Then I am taken to the editor with the proposed value prefilled and a draft version is created without impacting the Active version until published. Given I dismiss a suggestion, Then it is hidden for 30 days or until the metric improves/worsens by ≥10%, whichever occurs first. Given a suggestion is accepted and published, When sufficient post-change data is collected (e.g., 14 days or 200 deliveries), Then the system displays measured impact versus baseline with uplift and confidence. Given multiple suggestions qualify, Then no more than 3 active suggestions are shown per sequence and they are prioritized by expected impact.

A/B Testing for Step Copy and Timing

Given a step supports variants, When I create variants A and B for copy and/or timing, Then I can set traffic split (10–90 granularity) and minimum sample size per arm. Given the test runs, When recipients are enrolled, Then each recipient is randomly assigned to a variant and remains in that variant for all related messages. Given reporting is available, When minimum sample size and time window are met (e.g., 200 deliveries per arm and 7 days), Then the UI shows per-variant conversion to booking, lift, and statistical confidence, and highlights a leader if confidence ≥95%. Given I declare a winner, When I click Roll Out, Then the winner is set to 100% traffic, the loser is archived, and historical data is retained. Given Auto-Winner is enabled, When significance ≥95% after minimum sample is reached, Then the system auto-rolls out the winner and notifies me.

Thread Sync

Links the original conversation to the booking, notes, and invoice with a clean timeline of messages, offers, and confirmations. Gives you a single place to review context, audit decisions, and send updates or reschedule links without tool-switching.

Requirements

Email & SMS Thread Connectors

"As a solo practitioner, I want SoloPilot to automatically sync my email and SMS conversations so that all session context and client communications appear in one place without manual copy‑paste."

Description

Provide first‑class connectors for Gmail/Google Workspace and Microsoft 365 (Graph API) plus an SMS gateway (e.g., Twilio) to ingest and send messages while preserving native threading. Normalize emails/SMS into a common message schema including headers, participants, timestamps, and delivery status, and store minimal content needed for context. Support OAuth, token refresh, rate limiting, retries with exponential backoff, idempotent ingestion, and deduplication via Message‑ID/In‑Reply‑To/References and SMS conversation identifiers. Map messages to SoloPilot contacts and surface them in bookings, notes, and invoices by thread ID. Enable two‑way sync so messages sent from SoloPilot appear in the user’s mailbox/SMS history with proper sender identity, signatures, and reply‑to routing. Integrate with workspace settings for provider connection, per‑channel enablement, and health diagnostics.

Acceptance Criteria

OAuth Provider Connection & Health Diagnostics

Given a workspace admin opens Settings > Connectors, When they connect Gmail or Microsoft 365 via OAuth with least-privilege scopes, Then access and refresh tokens are stored encrypted-at-rest, scopes are recorded, and Health shows Connected with provider name, granted scopes, and last sync timestamp. Given the access token expires, When background sync triggers, Then token refresh succeeds without user intervention and Health remains Connected. Given token refresh fails (e.g., invalid_grant) or consent is revoked, When the next sync attempt occurs, Then connector status changes to Action Required with provider error code/message and a Reconnect action, And ingestion/sending are suspended until resolved. Given per-channel enablement toggles, When the admin disables Email or SMS, Then new ingestion and outbound for that channel stop within 60 seconds, existing timelines remain visible, and the toggle change is audit-logged with actor, time, and previous/new values.

Ingest & Normalize Emails/SMS into Common Schema

Given an inbound email from Gmail/Graph or SMS from Twilio is received via webhook or poll, When the message is processed, Then a message record is created using the common schema with fields: provider, direction, thread_id, message_id, in_reply_to, references, participants (from/to/cc/bcc or phone), subject (email only), timestamp (UTC ISO 8601), body_snippet ≤ 500 chars, attachment metadata (name,size,MIME,hash), and delivery_status initial value. Given data minimization rules, When storing content, Then only headers, participants, and body_snippet are stored; full body content is not persisted; attachments are not stored, only metadata and secure fetch URL if applicable. Given PII redaction rules, When generating body_snippet, Then credit card numbers and SSNs are masked to policy, and redaction is verifiable in stored snippet.

Deduplicate & Preserve Native Threading

Given the same email arrives via both push and poll or an SMS webhook is retried, When ingestion runs, Then processing is idempotent and duplicates are discarded using Message-ID/In-Reply-To/References for email and Conversation SID + Message SID for SMS, producing at most one stored record and one timeline entry. Given an email without a Message-ID, When ingesting, Then a deterministic surrogate ID (hash of normalized headers + date + provider id) is generated and used for deduplication. Given replies and forwards, When assigning thread_id, Then native threading is preserved using References/In-Reply-To for email and Conversation SID for SMS so that messages appear in a single timeline in chronological order. Given provider events are out-of-order, When ordering timeline, Then final ordering uses provider timestamp and a stable tiebreaker so the timeline matches the provider thread view.

Map Messages to Contacts and Surface by Thread ID

Given a message's participants match existing SoloPilot contacts by verified email or phone, When ingestion completes, Then the message is linked to those contacts and indexed by thread_id. Given a user opens a booking, note, or invoice linked to the same contact(s) and thread_id, When viewing the Thread Sync panel, Then the last 20 messages render within 300 ms p95 with channel filters (Email/SMS) and message direction indicators. Given no matching contact exists, When ingestion detects a new participant, Then a suggested contact match is displayed with Add/Link actions; upon user confirmation, the timeline reindexes to include the message within 5 seconds. Given multiple contacts share an alias, When ambiguity is detected, Then the system flags the message as Unlinked and requires explicit user selection before linking.

Outbound Send Mirrors to Provider with Identity & Replies

Given a user replies from Thread Sync using a connected Gmail or Microsoft 365 account, When sending, Then the message is sent via the provider API with From/Sender/Reply-To matching the selected workspace identity and existing DKIM/SPF alignment is preserved; the email appears in the provider Sent folder within 10 seconds and remains in the native thread via proper In-Reply-To/References or Graph conversationId. Given an outbound SMS, When sending via Twilio, Then the message is recorded with provider message SID, appears in Twilio logs, and is delivered to the recipient, with delivery status transitioning queued→sent→delivered/failed and provider codes stored. Given a recipient replies to email or SMS, When provider notifies, Then the reply is ingested and appended to the same timeline within 15 seconds p95, preserving threading and participant attribution.

Rate Limits, Retries, Backoff, and Error Reporting

Given provider APIs return 429 or 5xx, When retrying, Then exponential backoff with jitter is used starting at 1s doubling to a max of 5m with a cap of 7 attempts, respecting Retry-After headers when present. Given retries are exhausted, When the operation still fails, Then the item is moved to a dead-letter queue with correlation ID, surfaced in Health Diagnostics with provider code and last attempt time, and a one-click Reprocess action is available. Given sustained high throughput, When hitting provider quotas, Then the system auto-throttles to stay within limits, maintaining p95 API error rate < 1% and no data loss; backfills progress is reported with remaining count and ETA. Given transient network failures, When idempotent operations are retried, Then no duplicate sends or duplicate ingests occur and timeline integrity is maintained.

Auto‑Association Engine

"As a consultant, I want messages to auto‑link to the right session and invoice so that I don’t waste time organizing threads or risk missing billable details."

Description

Automatically associate incoming/outgoing messages with the correct booking, client notes, and invoice using deterministic and heuristic signals: participant matching to contacts, unique tokens embedded in scheduling/reschedule/offer links, subject markers, proximity to session date/time, and invoice numbers. Provide a confidence score with a review queue for low‑confidence matches and allow one‑click manual override and bulk reassignment. Handle late associations when bookings are created after messages arrive, and reindex on entity updates. Prevent duplicates across related entities by enforcing a single source thread with cross‑links. Expose association events to the audit log and surface suggested matches in the UI for quick confirmation.

Acceptance Criteria

Deterministic Association via Unique Tokens and IDs

Given an inbound or outbound message includes a valid SoloPilot scheduling/reschedule/offer link token or an invoice number When the Auto-Association Engine processes the message Then it associates the message to the referenced booking and marks the booking's primary thread as the source And cross-links any existing related notes and invoice to that same thread; if not yet created, it defers linking and schedules a late association And sets confidence_score to 1.0 and method="deterministic" And completes the association within 3 seconds of message ingestion And records an audit event "association.created" with fields: message_id, entity_type, entity_id, method, token_type, token_value, actor="system", timestamp

Heuristic Association by Participant Match and Time Proximity

Given a message lacks deterministic tokens but all participants map to a single SoloPilot contact And that contact has exactly one booking within ±14 days of the message timestamp When the engine processes the message Then it computes a confidence_score using participant match, time proximity to the session, and subject markers And if confidence_score ≥ 0.85, it auto-associates the message to that booking within 5 seconds and logs method="heuristic" And if 0.60 ≤ confidence_score < 0.85, it does not associate but places the message in the Review Queue with the top 3 suggested bookings and reason breakdown And if confidence_score < 0.60 or participants map to multiple contacts, it leaves the message unassociated and visible in the Unmatched list

Confidence Thresholds and Review Queue Workflow

Given a message is routed to the Review Queue When the user opens the queue item Then the UI displays: current confidence_score (0.00–1.00), top 3 candidate entities (booking/notes/invoice), and reason codes (e.g., participant_match, time_proximity, subject_marker) And the user can Confirm any candidate in one click or Dismiss all And on Confirm, the engine associates the message within 1 second, sets method="review_confirmed", and writes an "association.created" audit event with reviewer_id And on Dismiss, the message remains unassociated and an "association.dismissed" audit event is recorded And queue items are created within 2 seconds of message ingestion and sorted by descending confidence_score

One-Click Manual Override and Bulk Reassignment

Given a message is associated to an entity When a user clicks "Associate to…" and selects a different booking/notes/invoice Then the engine reassigns the message in one step, updates cross-links to the booking's primary thread, and records an "association.updated" audit event with method="manual" And the new association is locked (override_lock=true) to prevent future automatic re-assignment unless explicitly unlocked by a user And previous duplicate links (if any) are removed so the message appears once in the timeline And bulk reassignment supports selecting 1–500 messages, completes within 60 seconds, applies the same lock behavior, and records one "association.bulk_updated" parent audit event plus per-message child events

Late Association and Reindex on Entity Updates

Given messages arrive before a booking, notes, or invoice is created for a contact When the entity is created or updated (e.g., new booking; booking date/time change; contact email/phone update) Then the engine re-indexes impacted messages within 10 seconds, recomputes confidence, and links messages meeting auto-association thresholds And manual-override (override_lock=true) associations are never changed by reindex And on booking date/time updates, messages may be moved to a different booking only if the new confidence increases by ≥ 0.15 and is ≥ 0.85, with an "association.moved" audit event capturing before/after entity IDs and scores And late associations respect deterministic tokens (priority over heuristics) when present in historical messages

Single Source Thread and Duplicate Prevention Across Entities

Given a booking has a designated primary thread ID When messages are associated via deterministic or heuristic methods Then notes and invoice entities cross-link to that same primary thread rather than creating separate threads And a message cannot be associated as primary to more than one thread for the same booking (enforced via a unique constraint on message_id + booking_id) And the UI timeline displays each message once per booking, with links to related notes and invoice, and no duplicates even under concurrent updates And attempts to create a second primary thread for a booking are rejected with a clear error and no partial writes

Audit Logging and Suggested Matches in UI

Given any association create/update/delete occurs When the event is written to the audit log Then the record includes: message_id, entity_type, entity_id, action (created|updated|deleted|moved|dismissed), method (deterministic|heuristic|review_confirmed|manual|bulk), confidence_score (if applicable), reason codes, actor_id (system or user), and timestamp And audit events are immediately queryable via the admin audit UI and API And for unassociated or low-confidence messages, the UI surfaces suggested matches (up to 3) with confidence and reason chips, and a one-click Confirm that performs the association and logs the event

Unified Thread Timeline

"As a therapist, I want a single timeline showing all communications and related events for a session so that I can quickly review context and make informed decisions without switching tools."

Description

Render a chronological, consolidated timeline that merges emails, SMS, booking events (scheduled, rescheduled, canceled), offers/acceptances, notes creation/edits, invoice creation/sends/payments, and system automations into a single view. Provide inline previews of message bodies and attachments with quick open/download, visual tags for event types, avatars for actors, and delivery/read status where available. Include filters (event type, date range, participant), full‑text search over message metadata/content (respecting permissions), and deep links to the underlying booking, note, or invoice. Embed the timeline on client profile, booking detail, note, and invoice pages, with responsive design for mobile. Support pagination/virtualization for performance and export to PDF for audits.

Acceptance Criteria

Chronological Consolidation and Event Metadata Display

Given a client thread contains emails, SMS, booking events (scheduled, rescheduled, canceled), offers/acceptances, notes (created/edited), invoices (created/sent/paid), and system automations with timestamps When the Unified Thread Timeline loads Then all events are rendered in a single list sorted by event timestamp ascending with a deterministic tie-breaker on created_at then event_id And each event shows a visual tag for its type, the actor avatar (or system icon), and channel delivery/read status when provided by the source And interleaved events from different sources are shown without duplication and with accurate timestamps localized to the viewer's timezone

Inline Message and Attachment Preview with Quick Actions

Given an email or SMS event with body text and one or more attachments (images, PDFs, other files) in the timeline When the user expands the event preview Then the message body renders with safe formatting and line breaks preserved And supported attachments display inline previews (image thumbnails; first page of PDF); unsupported types show a file-type icon And clicking Open displays the full message or attachment; clicking Download initiates a download using the original filename And if the user lacks permission to view an attachment, the preview is replaced with a locked placeholder and Open/Download are disabled

Filtering by Event Type, Date Range, and Participant

Given the timeline filters for Event Type (multi-select), Date Range, and Participant are available When the user applies any combination of these filters Then only events matching all active filters are displayed in the timeline And active filters are shown as removable chips and a Clear All action resets the view to unfiltered And if no events match, an empty state is shown with an option to clear filters And active filters persist for the user within the same client context during the current session

Full-Text Search with Permission Enforcement

Given the user has permission to view a subset of messages, notes, bookings, and invoices in the thread When the user searches using a text query Then results include only events the user is authorized to view and that match the query in message subject, body, note content, booking title, or invoice number And matching terms are highlighted within the inline preview And search respects any active filters and date range And clearing the query restores the prior filtered timeline

Deep Links to Underlying Records

Given each timeline event exposes a deep link to its source record (booking, note, invoice, email/SMS) When the user activates the deep link Then the app navigates to the correct record view in the same workspace with the record loaded And if the record has been deleted or the user lacks permission, an error state is shown with a safe back-to-timeline option And returning to the timeline restores the prior scroll position and active filters/search

Embedding and Responsive Mobile Layout

Given the timeline component is embedded on Client Profile, Booking Detail, Note, and Invoice pages When each page is viewed on desktop and mobile (>=320px width) Then the timeline renders the same functionality on all host pages with no horizontal scrolling on mobile And interactive targets meet minimum 44px touch size and content reflows to fit the viewport And avatars, tags, and status indicators remain visible and legible at all breakpoints

Pagination/Virtualization Performance and PDF Export

Given a thread with 5000+ events When the user loads the timeline Then the first 50 events render within 2 seconds and additional pages load in increments of 50 within 1 second And virtualized scrolling maintains smooth interaction without visible jank and mounts only visible items to keep memory usage stable And reaching the end of available events displays an end-of-timeline indicator And when the user clicks Export to PDF, the generated PDF reflects the current filters/date range/search, preserves chronological order, includes a header with client name and generation timestamp, numbers pages, and downloads with filename pattern clientname_thread_YYYYMMDD.pdf

Timeline Actions & Templates

"As a coach, I want to send confirmations and reschedule links directly from the thread view so that I can respond faster and keep all communication in one place."

Description

Enable action controls directly from the timeline to compose and send email/SMS updates, reschedule links, offers, confirmations, and payment nudges without leaving the page. Provide a template library with variables (client name, session date/time, location/telehealth link, invoice amount, due date) and preview before send. Allow attaching files from notes or uploads, scheduling messages for later, and inserting one‑time secure links. Respect channel availability and sender identity settings, and log all sends back to the same thread with status updates. Expose quick actions (Confirm, Reschedule, Send Receipt) and keyboard shortcuts to accelerate workflows.

Acceptance Criteria

Compose and Send from Timeline with Template Variables and Preview

Given a user is viewing a client thread timeline linked to an upcoming session and invoice When the user opens the composer, selects a template, and chooses a channel (Email or SMS) Then the template auto-populates variables: client_name, session_datetime (with timezone), location_or_telehealth_link, invoice_amount, due_date from the linked records And any unresolved or missing variable is highlighted and blocks sending with a clear validation message And a preview shows the exact rendered outbound content for the chosen channel When the user edits the body or variable fields Then the preview updates in real time When the user clicks Send Then the message is dispatched over the selected channel without leaving the page and the sent content snapshot is stored with the message

Channel Availability and Sender Identity Enforcement

Given the client record has channel availability settings and the workspace has verified sender identities When the user opens the channel selector in the timeline composer Then unavailable channels are disabled with explanatory tooltips And the default From identity is preselected based on workspace rules for the chosen channel When no verified identity exists for the selected channel Then sending is blocked with a clear error and a link to manage sender identities And the system does not auto-switch channels without explicit user confirmation

Attach Files and Insert One‑Time Secure Links

Given client notes and uploads contain files When the user clicks Attach and selects files from Notes or Uploads Then the files are attached to the outbound message with source labels and can be removed before sending When the user inserts a One‑time secure link to an attachment Then a unique link token is generated and inserted into the message And after the first successful access the link expires and cannot be opened again And the timeline records an access audit event with timestamp and recipient identifier When the message is sent Then attachments and secure link metadata are logged to the same thread

Schedule Send with Edit/Cancel and On‑Time Delivery

Given the user composes a message in the timeline When the user selects Schedule for Later and sets a future date and time Then the message is saved as Scheduled with the chosen timestamp visible in the thread And the user can edit the content, change the scheduled time, or cancel before it is sent At the scheduled time Then the system dispatches the message within 60 seconds of the scheduled timestamp And the timeline updates status from Scheduled to Sent (or Failed) with exact send time When a scheduled message is canceled Then no outbound is dispatched and the thread shows Canceled with audit details

Quick Actions and Keyboard Shortcuts

Given a session in the thread is Pending and an invoice exists When the user clicks the Confirm quick action or presses the shortcut (e.g., C) Then the session status updates to Confirmed, a confirmation message is sent using the default confirmation template, and the event is logged in the thread When the user clicks Reschedule or presses the shortcut (e.g., R) Then a reschedule link is inserted using the booking context, the reschedule message is sent, and the thread records the action When the user clicks Send Receipt or presses the shortcut (e.g., G) after a payment is recorded Then a receipt message is sent to the client and logged with the associated invoice When the user presses ? in the timeline Then a shortcut help overlay appears listing available shortcuts for visible quick actions

Thread Logging and Delivery Status Updates

Given any message is sent or scheduled from the timeline When the action updates status (Queued, Sent, Delivered, Failed) Then an entry is added to the same thread including timestamp, channel, sender identity, template name (if used), and a non-editable snapshot of the content And delivery status updates in place without page reload and records status transitions with times When a send fails Then the thread entry shows Failed with error detail, a Retry action is available, and a subsequent retry attempt is logged as a separate status update

Payment Nudge with Invoice Variables and Pay Link

Given an open or overdue invoice is linked to the thread When the user selects the Payment Nudge action in the composer and chooses a channel Then the message body auto-populates invoice_amount, due_date, and a secure pay_link And the preview shows the full rendered message including the pay_link When the user sends the nudge Then the message is dispatched, the thread logs the send with invoice reference, and the invoice timeline records the nudge event

Audit & Compliance Trail

"As an owner, I want a reliable audit trail of communications and changes so that I can verify decisions and meet client or regulatory requests with confidence."

Description

Maintain an immutable event ledger capturing message ingestion, associations, edits, unlink/relink actions, note revisions, invoice updates, and timeline sends, with user, timestamp, and before/after metadata. Store message metadata and content hashes to prove integrity without exposing sensitive content unnecessarily. Provide configurable retention policies, exportable audit reports per client or session, and time‑boxed access links for auditors. Surface a readable change history within the timeline and expose structured events via API/webhooks for compliance and external archiving.

Acceptance Criteria

Immutable Event Ledger for Thread Sync Actions

Given Thread Sync is enabled and a user performs a supported action (message ingested, message linked/unlinked/relinked, note revised, invoice updated, timeline message sent) When the action is committed Then an append-only audit event is persisted within 2 seconds containing event_id (UUIDv4), event_type, workspace_id, actor_id and actor_type, entity_type and entity_id, correlation_id, timestamp (UTC ISO-8601 ms), before, after, and relevant content hashes Given an audit event exists When any attempt is made to update or delete it via API, UI, or DB Then the operation is rejected with 405 and a new correction event is appended with reason and reference to the original event_id Given audit events exist for an entity When they are retrieved by API or timeline Then they are returned strictly ordered by a per-entity monotonic sequence and globally sortable by timestamp then event_id Given an event write fails transiently When retry logic runs Then the system retries up to 5 times with exponential backoff and marks the UI timeline item as Pending until success or PermanentFailure is raised

Message Integrity Hashing Without Content Exposure

Given a message is ingested from any channel When stored in the audit ledger Then SoloPilot stores message metadata (channel, sender, recipient, external_id, received_at) and a SHA-256 content_hash of the canonicalized body, but does not store the plaintext body in the ledger Given content canonicalization rules (normalize line endings to LF, trim trailing spaces, collapse consecutive whitespace) When hashing is computed Then the same input produces the same hash across channels and platforms Given a message hash exists When a verification request is made with the original content Then the verify endpoint returns Match when the SHA-256 of canonicalized content equals stored content_hash, else NoMatch, without persisting the submitted content Given message headers or bodies contain PII When audit events are created Then PII is not written to audit event fields; only hashes and non-sensitive metadata are stored; events that would leak PII are rejected and logged

Configurable Retention and Legal Hold

Given a workspace admin defines retention policies per category (messages, notes, invoices, audit_events) with durations between 30 and 3650 days When policies are saved Then changes are validated, versioned, recorded as audit events, and take effect at the next retention job run Given retention policies are active When the nightly purge job runs Then events older than their category retention are irreversibly purged within 24 hours, except items under legal hold Given a legal hold is placed on a client or session with a reason and scope When purge evaluation runs Then scoped items are excluded from purge and attempts to delete them via API return 423 Locked with a reference to the legal_hold_id Given an admin previews a policy change When requesting an impact report Then the system returns a count of items by category scheduled for purge and an estimated completion time

Exportable Audit Report by Client or Session

Given an admin selects a client or session and a date range When requesting an audit export Then the system generates a report in CSV or JSON containing all matching audit events ordered by timestamp then event_id, and produces a manifest with totals and a SHA-256 checksum for each file Given the matching set is ≤ 50,000 events When the export is requested Then the download link is available within 120 seconds; otherwise the request is queued and the admin is notified via in-app and email when ready Given an export is generated When it is downloaded Then the file is signed with a detached HMAC-SHA256 signature using the workspace export secret and the manifest includes the signature and key_id Given an export link is created When it expires after its TTL Then access returns 410 Gone and the file is removed from temporary storage

Time-Boxed Auditor Access Links

Given an admin creates an auditor access link scoped to a specific client, session, or date range When the link is issued Then it is read-only, uses a random 32-byte token, can be configured to require a passcode or OTP, and has a TTL between 1 and 30 days with a maximum download limit Given an auditor visits the link When authentication is satisfied Then the auditor can view and download only the scoped audit report and cannot see other clients, sessions, or PII; all access is logged with IP, user-agent, and timestamp Given a link is revoked or expires When access is attempted Then the system returns 401/410 and no data is leaked; revocation takes effect within 60 seconds globally

Readable Change History in the Thread Timeline

Given a user opens a client or session timeline When audit events exist Then each event is displayed with a human-readable summary (who, what, when, which entity), with expand/collapse to view before/after diffs and a link to raw JSON Given the timeline has more than 200 events When scrolled Then events are virtualized and load progressively, maintaining 95th percentile render times under 300 ms per batch Given a user has a preferred timezone When viewing timestamps Then the UI shows local time with a toggle to UTC; all timestamps include seconds and milliseconds Given the user searches or filters by event type, actor, or date range When applying filters Then the timeline updates within 500 ms and the current filter state is reflected in the URL for sharing

Description

Enable upload of attendee rosters via CSV or copy-paste, with column mapping for email, name, tags, and program. Bulk-apply sponsor roster tags, set eligibility dates, and resolve duplicates by email. Changes to rosters update sponsor associations for future bookings and optionally for unsent invoices. Provide validation feedback, preview of impacted attendees, and activity logs. Supports scheduled roster refresh via secure link or integration hook to keep eligibility current ahead of workshops.

Acceptance Criteria

WORM Sentinel

Locks every note, upload, and edit as append‑only with cryptographic fingerprints and chain‑of‑custody receipts. You get instant proof of integrity and a clear addendum trail for corrections—no risky overwrites. Tamper signals trigger alerts and a verification report you can hand to auditors or insurers in seconds.

Description

Offer prebuilt and customizable policy templates (e.g., Client View, Supervisor Review, External Auditor) that bundle expiry, watermarking, mask sets, export permissions, IP/time rules, and break-glass behavior. Allow admins to set workspace-level defaults by object type and automation (e.g., session-to-invoice shares use Client View for 7 days). Enable one-click template application during sharing, bulk-update of active links when a template changes, and versioning to track policy evolution. Provide an API for managing templates, a recipient preview to validate outcomes, and analytics to report template usage, overriden shares, and risky exceptions.

Acceptance Criteria

Discovery Export

Produce court‑ready, immutable exports with Bates numbering, checksums, and a signed manifest. Built‑in redaction removes PII/PHI from selected fields or pages without altering originals, and a privilege log documents what was withheld. Delivers a zipped, searchable set that satisfies eDiscovery requests without manual tedium.

Product Details

Vision & Mission

Problem & Solution

Details & Audience

User Personas

Intake Integrator Imani

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

Afterhours Arranger Alex

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

Timezone Tamer Theo

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

Workshop Wrangler Wren

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

Package Planner Priya

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

No-Show Neutralizer Nova

Background

Needs & Pain Points

Needs

Pain Points

Psychographics

Channels

Product Features

Intent Detect

Requirements

Channel Connectors & Unified Message Ingestion

Description

Acceptance Criteria

Intent Classification with Confidence Thresholds

Description

Acceptance Criteria

Entity Extraction for Scheduling Parameters

Description

Acceptance Criteria

Availability Mapping & Booking Draft Generation

Description

Acceptance Criteria

One-Click Confirm & Smart Reply Composer

Description

Acceptance Criteria

Human Review, Corrections, and Personalization Loop

Description

Acceptance Criteria

Privacy, Security, and Compliance Controls

Description

Acceptance Criteria

Inline Slots

Requirements

Live Availability Sync & Conflict Prevention

Description

Acceptance Criteria

Timezone Detection & Locale Rendering

Description

Acceptance Criteria