Product Roadmap
What we're building, what's next, and what just shipped.
Planned
51Phase 1: Attribution tracking on every action
Every write records who made the change and on whose behalf. Foundation for the Working-On and Act-As features and for clean audit trails. Adds attribution columns to every data table — landing this early avoids expensive retrofits later.
Phase 2: Switch client and act on behalf of others
Consultants switch which client they are viewing via a sidebar dropdown. Admins can act on behalf of another user (for support or delegation) with full audit capture. Visual state makes the mode unmistakable — grey for viewing, red for acting-as.
Phase 3: Password reset, two-factor auth, welcome emails
Forgot-password flow with one-hour email links. Two-factor authentication via authenticator app with recovery codes. Welcome, password-reset, and password-changed emails sent automatically.
Phase 4: Lock the active-client selector
A lock icon next to the client selector prevents accidental switching while working. Persists per session; resets on re-login.
Phase 1: Platform-wide event bus
Every data change emits an event that other features subscribe to. Powers notifications, activity logs, search indexing, and webhooks — all from a single source. Foundation layer; nothing user-visible ships from this phase alone.
Phase 1: Notification bell and preferences
Bell icon in the header with unread count. Preferences page lets users pick which event categories they want notified about, per channel.
Phase 2: Notifications page and drawer
Click the bell to see the 10 most recent notifications in a drawer. Full notifications page with unread/read tabs, category filter, bulk mark-as-read, and per-row actions.
Phase 3: Email notifications with per-category preferences
Notifications also delivered by email. Settings > Notifications lets users toggle email per category. Viewer-role users get no email by default (read-only audience); Account notifications are locked on.
Phase 2: Per-client activity timeline
Consultants see a per-client timeline of what happened: documents uploaded, knowledge added, challenges resolved, users invited. Filter by category, group by date, infinite scroll.
Phase 3: Master Admin forensic audit log
Platform admin sees every write across every tenant with filters, full-text search, CSV export, and 2-year hot retention. Used for incident response and compliance audits. Not visible to consultants.
Phase 4: Weekly digest and inbox cleanup
Opt-in weekly summary delivered Monday 8 AM local time. Old read notifications are cleared after 90 days to keep the inbox manageable.
Phase 1: Search index across all features
Background index keeps a searchable copy of everything a user has access to. Updates live when data changes. Foundation layer; no user-visible surface in this phase.
Phase 2: Keyword search with smart ranking
Fast keyword search with typo tolerance. Results ranked by relevance, recency, and document status. Archived items remain findable but deprioritised.
Phase 4: Connect search and user-context to the event bus
Search index and user-context tracking plug into the platform event bus. Search stays fresh as data changes. User-context actions appear in the activity log.
Phase 3: Cmd+K / Ctrl+K search palette
Hit Cmd+K (Mac) or Ctrl+K (Windows/Linux) from anywhere in the app to search across documents, findings, clients, research, and reports. Results grouped by type.
Phase 1: Capture and catalogue all errors
Every error users hit is captured with full context. A curated catalogue maps errors to human-readable messages (what happened, why it happened, what to do next).
Phase 2: Friendly error messages with silent retry
Users see clear, actionable messages instead of raw stack traces. Transient errors (timeouts, rate limits) retry silently in the background. Every message includes a reference ID for support conversations.
Phase 3: Master Admin error review queue
New error signatures queue up for review. Master Admin adds them to the catalogue so future users see a friendly message instead of a generic fallback.
GDPR compliance and privacy documents
Seven public legal documents (Privacy Policy, Terms of Service, Data Processing Addendum, Subprocessor List). Consent tracking with document version history. Re-consent banner on material changes. Data Subject Access Request tooling. Retention schedules. Ships first due to Swisscontact legal requirement.
Account protection: breach check, rate limits, isolation tests
Password minimum raised to 12 characters with compromised-password check against a public breach database. Login rate-limited (5 failures in 15 minutes triggers 30-minute lockout). Per-table cross-tenant isolation tests in continuous integration. Security headers on every response. Alerts on failed-login spikes.
User Security settings page
Users manage password, two-factor auth, active sessions, login history, and legal-document consents from a single Settings > Security page. Destructive actions (delete account, sign out everywhere) clearly marked.
Incident response and internal policies
Internal documents: Incident Response Plan (72-hour AZLP notification workflow), Access Policy, Employee Onboarding/Offboarding Checklists, Security Training Guide, Vendor Risk Management, Backup and Recovery procedures. Annual restore test and tabletop exercise.
SOC 2 Type I readiness tracker
Internal tracker mapping platform controls to ~50 SOC 2 Trust Criterion requirements. Used to answer enterprise security questionnaires and prepare for a future SOC 2 Type I audit. Maintained continuously.
Phase 4: Error alerts and automated tests
New error signatures notify Master Admin (deduplicated, max once per day). Weekly digest of error trends. Comprehensive test coverage for capture, catalogue, and review flows.
Phase 3: Activity log integration for Act-As actions
Every Act-As session is logged with both the real actor and the target user. Activity timelines show "[actor] on behalf of [target]" for affected entries.
Phase 4: Safety rails on sensitive actions
Seven sensitive actions (password change, MFA, email, billing, account deletion, etc.) are blocked while acting on behalf of another user. Prevents privilege escalation via identity substitution.
Phase 1: Create and manage API keys
Consultants and clients generate API keys from Settings > API Keys, scoped by direction (read / write / both), feature set, and client set. Tokens shown once at creation; only an 8-character prefix after. Keys appear in an audit-ready log.
Phase 2: Read data via API
Read endpoints across Pulse Report, Data Room (metadata + signed URLs), Roadmap, Knowledge Base, Diagnostic Registry, Market Research, Building Diagnostic. Cursor pagination. Per-key scope validation.
Phase 3: Write data via API with idempotency
Write access limited to Roadmap tickets/comments, Data Room uploads, and KPI values. Idempotency keys prevent duplicate writes on retries. Hourly rate limits; Master Admin can override per key.
Phase 4: Webhooks for real-time integrations
Register HTTPS endpoints to receive events (~18 curated event types). HMAC-signed payloads, at-least-once delivery with retry schedule. Dead-letter dashboard with resend button. Signing secret rotation with dual-validity window.
Phase 5: Developer docs portal
Published API documentation at developers.businesspulseos.com. Auto-generated OpenAPI spec. Getting-started guide, endpoint reference, event catalog, webhook guide, rate limits, changelog. URL-prefix versioning (/v1/) with 12-month support minimum after /v2/ launches.
Phase 3: Feature requests and comments
Authenticated or verified users submit feature requests via a form. Inline comment thread on every item (15-minute edit window). Rate-limited to prevent spam.
Phase 4: Weighted voting
Upvote feature requests. Paying customers weigh 5x, verified visitors 1x. Cards show raw counts and weighted score. Sort order defaults to score descending so the community surfaces what matters most.
Phase 5: Changelog publishing and notifications
Master Admin publishes a Changelog entry when items ship. Voters on shipped items are notified. Submitters notified on admin responses. Email-only notifications for visitors.
Phase 1: Store facts, derived findings, and entities
Per-client knowledge store: facts extracted from documents, derived findings computed from facts, cross-document findings, entities (competitors, customers, products, markets, people), and knowledge gaps. Every entry carries a version snapshot so downstream citations stay stable.
Phase 2: Automatic recipe-driven knowledge extraction
Recipes fire automatically when new facts arrive, producing derived findings. Cross-document pattern detection surfaces insights a human would miss. Consultant reviews medium/low confidence entries before they enter the library.
Recipe catalogue — platform-curated, consultant-contributed
Platform ships an initial library of knowledge-extraction recipes. Consultants contribute new recipes that apply immediately for their clients and queue for Master Admin review. Approved recipes propagate to all tenants.
Phase 3: Inline Knowledge editor in Data Room
Add or edit Knowledge Base entries without leaving the Data Room document view. Master Admin reviews consultant-contributed recipes for inclusion in the platform-wide catalogue.
Phase 1: AI-powered research with a single methodology
Consultants dispatch research requests (from Diagnostic Registry or directly) that the platform executes asynchronously. Output lands back in the Data Room as a structured, source-cited research document. Consultant reviews before the research enters Knowledge Base.
Phase 2: Multiple research methodologies and layered research
More than one research prompt template, so consultants can pick the right approach for each question. Multi-layer research blocks that break a broad question into parallel child queries, then aggregate results.
Phase 1: Research areas and hypotheses
Each diagnostic engagement starts with research areas (3-4 thematic concerns) and hypotheses (what the consultant thinks is happening in each area). Hard-locked at creation so the analytical frame stays stable through the engagement.
Phase 2: Match findings, interpret, and fill gaps
The work loop: match Knowledge Base findings to each hypothesis, AI-draft interpretations for consultant review, identify gaps, dispatch research to close gaps, re-match with new findings. Tools for the consultant to review and edit each AI draft.
Phase 3: Synthesis and Strategic Challenges
Cross-finding synthesis produces Synthesis Items with severity ratings and reinforcing loops. At report time they consolidate into Strategic Challenges (Section 5 of the diagnostic report). Soft-lock then hard-lock lifecycle prevents drift after publication.
Phase 1: 17-step guided diagnostic workflow
The full BizzBee V3 diagnostic methodology as a guided workflow. 17 steps from initial client meeting through to final report, with AI assistance at every step. Hosted on a reusable workflow engine that also runs simpler templates (e.g. SWOT-only).
Phase 2: Research dispatch and review queue
The workflow dispatches research blocks to Market Research asynchronously. Completed research lands in a review queue; consultant approves before it enters Knowledge Base. Workflow continues once research is approved.
Phase 3: Final report generation
Synthesises the locked diagnostic registry, knowledge base, and SWOT into a publication-ready Word + PDF report with full citations. Published report archives to Data Room. Triggers Pulse Report population and locks the diagnostic permanently.
Phase 2: Smart conflict detection and cross-linking
Flags when new documents contradict existing knowledge so consultants can review. Automatically links entity mentions across documents. Shared citation layer lets Knowledge Base, Diagnostic Registry, and Pulse Reports cite documents with version snapshots.
Phase 1: Interactive client diagnostic report
Client-facing interactive presentation of the diagnostic: overview, per-challenge drilldown, SWOT. Replaces the static Word/PDF report with a web view the founder bookmarks and returns to. Populated by importing the published Word report; consultant edits in-app.
Phase 2: Challenges tab and accumulating history
Strategic Challenges tab with action roadmap per challenge. Challenges accumulate across multiple diagnostics with status (active / resolved / superseded). Full 4-tab PDF export. Each report publication creates an immutable version.
Phase 1: Client-facing kanban for implementation
Client engagement kanban where diagnostic actions become live tickets. Both consultant and client can create, edit, comment, assign. Per-client, persistent across diagnostics. The collaborative execution surface that follows the diagnostic.
Phase 2: Strategy mode with Strategic Challenges
Strategy mode imports Strategic Challenges from the latest diagnostic as grouped action batches. WISE action tagging (Substitute / Eliminate / Wise-by-design). Per-challenge action roadmap readable from Pulse Report Tab 4.
In Progress
0Nothing in flight right now.
In Review
6Phase 2: Manage users and client companies
Consultants invite users, edit users, add client companies, and assign users to clients. Existing role labels migrated to the Admin / Manager / Contributor / Viewer standard. Position field lets users self-identify (Founder, CEO, SDR, Consultant, etc.) without affecting permissions.
Phase 1: Internal roadmap kanban
Master Admin kanban at /admin/roadmap with three tabs: Roadmap (Planned / In Progress / Shipped), Requests (Under Review), Changelog. Create, edit, drag-drop status transitions, version snapshots. In progress.
Phase 2: Public roadmap website
Public page at roadmap.businesspulseos.com where anyone can read all three tabs. Logged-in BPOS users authenticate automatically. Non-customers verify via email magic link (90-day session). Filter and search.
User Management & Settings in the sidebar
Admins and managers now see User Management as a top-level sidebar entry; Settings lives in the footer. Contributors and viewers are blocked server-side.
Profile photo, notification preferences, and login count
Settings now includes a profile photo upload, email notification and weekly digest toggles, and total logins alongside last login — feature-matching the previous app.
Tighter, more information-dense Settings page
Settings and related surfaces use smaller headings, tighter card padding, and compact inputs for better information density.
Shipped
3Background job processing service
Platform service that runs long-running asynchronous jobs: document text extraction, media transcription, recipe firing, scheduled cleanups, weekly digests. Features call a stable interface; the underlying vendor is swappable without touching feature code. Shipped alongside Data Room Phase 1.
Phase 1: Login with email and social providers
Users sign in with email + password, Google, or Microsoft. Sessions timeout after 24 hours of inactivity. Four-role permission catalogue (Admin / Manager / Contributor / Viewer). Every data action is gated by row-level access control.
Phase 1: Upload documents, URLs, and media
Drag-and-drop upload for documents, URLs, and media files. Automatic text extraction, media transcription, and finding detection. Smart duplicate check prevents the same file entering twice. Live preview for every file type. Changes sync across browser tabs in real-time.