# ExpertFlow Catalog — Full Text for LLM Consumption # Generated by generate_llms_txt.py — do not edit manually # # Contains all Solution Patterns and Canon Axioms in structured plain text. # Each object is self-contained with sufficient context for LLM reasoning. # Features index is in llms.txt. ======================================================================== SOLUTION PATTERNS ======================================================================== Solution Pattern: Omnichannel Contact Center with CRM Integration ID: efv-sol-001 Target segments: financial-services, telco, healthcare, enterprise, government Description: Enterprises running voice, chat, email, and social channels alongside a CRM face a fragmented experience: agents toggle between systems, context is lost on transfer, and reporting is siloed by channel. ExpertFlow unifies every channel under a single conversation object and embeds agent controls directly into the CRM — Dynamics, Salesforce, or a custom desktop via open API — so agents never leave their workflow to handle a contact. Skills-based routing matches each interaction to the right agent in real time, and every conversation is linked to the CRM record automatically. Canonical use case: A regional bank with 300 agents handling phone, chat, and email through Salesforce. Agents today switch between three tools per call; managers cannot see cross-channel queue depth. ExpertFlow embeds a full agent desktop inside Salesforce, routes all channels via skills-based rules, and gives supervisors a unified real-time wallboard. Composed of features: efv-routing-001, efv-routing-002, efv-routing-011, efv-routing-003, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-cti-crm-001, efv-cti-crm-002, efv-cti-crm-005, efv-cti-crm-007, efv-cti-crm-008, efv-cti-crm-009, efv-conversational-ai-001, efv-conversational-ai-003, efv-core-objects-001, efv-core-objects-004, efv-core-objects-003, efv-security-001, efv-security-003 # Omnichannel Contact Center with CRM Integration ## Customer challenge Contact centres running multiple customer channels — voice, chat, email, social — typically manage them through separate tools. Agents are forced to context-switch between a phone softphone, a CRM record, a chat console, and a ticketing system. Transfers lose context. Reporting is fragmented. Supervisors cannot see the true state of the contact centre across all channels simultaneously. CRM teams and contact centre teams have historically bought separate products and integrated them with brittle middleware. When a customer calls after sending a chat, the agent starts the conversation from scratch. ## ExpertFlow's approach ExpertFlow treats every inbound or outbound interaction — regardless of channel — as a single **Conversation object** that carries the full context: participant identities, prior sessions, AI-generated summaries, and the linked CRM record. The agent desktop is embedded natively inside Microsoft Dynamics 365, Salesforce Service Cloud, or any CRM via ExpertFlow's open Agent Desktop API. Agents answer calls, accept chats, and handle emails without leaving the CRM. Screen-pop delivers the client record and interaction history at the moment of connection. Skills-based routing matches each incoming interaction to the best available agent using real-time agent state — not a static queue assignment — so the right person handles each contact. Supervisors have a live wallboard across all channels. ## Why ExpertFlow wins here Unlike CCaaS platforms that require a separate agent desktop and connect to CRMs via packaged connectors with limited data depth, ExpertFlow embeds directly inside the CRM using the CRM's own extension points. The conversation context lives in ExpertFlow's unified conversation model and is surfaced inside the CRM — agents see everything in one pane of glass. Open APIs mean the integration is not locked to a connector version or marketplace approval cycle. ## Typical deployment context 300–3 000 agent seats. Customer has an existing CRM licence (Dynamics or Salesforce) and wants to avoid rip-and-replace. May be running legacy Cisco or on-premise PBX for voice and wants to modernise the agent layer without replacing SIP infrastructure. Often regulated (finance, healthcare) — on-premise or private cloud deployment possible alongside cloud tenants. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Voice-Only Contact Center (SIP / WebRTC) ID: efv-sol-002 Target segments: utilities, financial-services, government, healthcare, mid-market Description: Businesses that primarily handle customer interactions by telephone — whether inbound support, outbound sales, or blended — need a reliable, low-latency voice platform with modern agent tooling. ExpertFlow delivers a full-featured voice contact centre over SIP trunks or WebRTC, requiring no hardware endpoints. Agents work from a browser-based softphone; supervisors have real-time queue visibility and call-monitoring controls. The platform integrates with any SIP provider and can run on-premise, in the cloud, or in a hybrid topology. Canonical use case: A utility company with 150 inbound call agents needs to replace an ageing on-premise PBX-based ACD. The replacement must support browser-based agents (no desk phones), retain existing SIP trunks, and provide real-time supervisor monitoring without a proprietary wallboard appliance. Composed of features: efv-routing-001, efv-routing-002, efv-routing-003, efv-routing-004, efv-routing-010, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-rtc-voice-005, efv-rtc-voice-006, efv-rtc-voice-007, efv-rtc-voice-008, efv-rtc-voice-011, efv-cti-crm-005, efv-core-objects-001, efv-core-objects-003, efv-security-001, efv-security-003 # Voice-Only Contact Center (SIP / WebRTC) ## Customer challenge Many organisations still handle the overwhelming majority of customer interactions by telephone and do not need — or are not ready for — a full omnichannel deployment. They need a voice platform that is reliable, easy to operate, and modern enough to support remote agents via browser without complex VPN or hardware phone provisioning. Legacy on-premise ACDs are reaching end-of-life and carry high maintenance costs. Cloud PBX alternatives often lack the routing sophistication or supervisor tools required for a true contact centre. ## ExpertFlow's approach ExpertFlow delivers a complete voice contact centre using open SIP standards and WebRTC for agent audio. Agents connect via browser — no softphone installation or desk phone required. SIP trunks from any ITSP connect directly to ExpertFlow's edge call-control layer, keeping voice media local and minimising latency. Skills-based routing directs calls to the most capable available agent using live agent state. IVR handles self-service and call deflection before queue entry. Supervisors can monitor calls, barge in, and view real-time queue metrics. All calls are recorded and stored against the conversation record. ## Why ExpertFlow wins here ExpertFlow's edge call-control model keeps signalling and media on the customer's network rather than routing through a cloud POP. This produces lower latency for geographically distributed contact centres and means voice quality is independent of internet connectivity to a cloud provider. Running on standard SIP means no carrier lock-in and no proprietary endpoint hardware. ## Typical deployment context 50–1 500 agent seats. Customer has existing SIP trunks they want to retain. Agents are distributed across offices or working remotely. May be regulated (healthcare, finance) requiring on-premise media handling. Often a first step before adding chat or AI automation channels. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: AI-Assisted Chat: Bot Automation with Human Handoff ID: efv-sol-003 Target segments: telco, financial-services, retail, e-commerce, utilities Description: Organisations deploying chat automation face a recurring failure mode: bots handle simple queries but drop context when escalating to a human, leaving the agent to restart the conversation. ExpertFlow's chat automation pattern pairs an LLM-grounded conversational bot with seamless human handoff — the full bot transcript, identified intent, and client record travel with the escalation. The bot is LLM-agnostic (swap models without reconfiguring the dialog layer) and grounded in the customer's own knowledge base via RAG, preventing hallucination on product and policy queries. Canonical use case: A telecommunications provider wants to deflect routine billing and account queries (60% of chat volume) to a bot, while ensuring complex complaints reach a skilled human agent with full context. The bot must answer questions from a live knowledge base without retraining, and the handoff must pass conversation history to the agent. Composed of features: efv-conversational-ai-001, efv-conversational-ai-003, efv-conversational-ai-004, efv-conversational-ai-005, efv-conversational-ai-007, efv-conversational-ai-010, efv-conversational-ai-011, efv-routing-001, efv-routing-003, efv-routing-002, efv-cti-crm-005, efv-cti-crm-007, efv-core-objects-001, efv-core-objects-003, efv-core-objects-004, efv-security-001 # AI-Assisted Chat: Bot Automation with Human Handoff ## Customer challenge Organisations adding chat to their customer service operations quickly discover that a bot alone is insufficient. Customers escalate when the bot cannot resolve their issue, and at that moment — the handoff — context is frequently lost. The agent receives an incoming chat with no bot transcript, no identified intent, and no knowledge of what was already attempted. Additionally, bots trained on static FAQ datasets become stale within weeks. Keeping them current requires expensive retraining cycles or model fine-tuning that locks the organisation to a single AI vendor. ## ExpertFlow's approach ExpertFlow deploys a conversational AI layer built on LangGraph and LangChain, connected to the customer's knowledge base via RAG (Retrieval-Augmented Generation). The bot answers queries by retrieving current content at runtime — knowledge base updates propagate immediately without model retraining. When the bot cannot resolve a query, it triggers a structured handoff through ExpertFlow's routing layer. The agent receives the full conversation transcript, the bot-assessed intent, the client's identity record, and any CRM context — inside their existing desktop interface. No context is lost; the agent continues where the bot left off. Agent AI Assist provides suggested responses and knowledge retrieval to accelerate resolution after handoff. ## Why ExpertFlow wins here ExpertFlow's LLM-agnostic architecture means the customer is not locked to a specific AI provider (OpenAI, Google, Azure AI). The dialog layer is decoupled from the underlying model — swap or upgrade the LLM without reconfiguring routing or handoff logic. Grounding through RAG means responses are always based on the customer's own content, not on model training data, which is critical for regulated industries and organisations with proprietary product catalogues. ## Typical deployment context Digital-first customer service teams deploying web chat or messaging app channels. Often deploying alongside voice (see efv-sol-001) as part of a broader omnichannel programme. Regulated industries (finance, healthcare) benefit from the on-premise LLM option where data cannot leave the network. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: AI Voice Bot with Human Handoff ID: efv-sol-004 Target segments: financial-services, insurance, healthcare, utilities, telco Description: Voice automation has historically been confined to DTMF-based IVR menus — frustrating for callers and limited in scope. ExpertFlow's AI voice bot pattern enables natural spoken conversation for the self-service layer, with clean handoff to a human agent when needed. Call forking sends audio to the AI layer without interrupting the SIP path, and the bot's intent summary, sentiment assessment, and full transcript are delivered to the agent at the moment of handoff. The voice bot is LLM-agnostic and grounded via RAG — answering from live knowledge without model retraining. Canonical use case: An insurance company handles 40% of calls as routine policy queries and claims status checks. A conversational voice bot handles these without menu navigation, understanding natural speech and retrieving answers from the policy knowledge base. Complex claims and complaints transfer to agents with the bot transcript and assessed intent already visible, cutting average handle time on escalated calls by 30%. Composed of features: efv-conversational-ai-002, efv-conversational-ai-003, efv-conversational-ai-004, efv-conversational-ai-005, efv-conversational-ai-007, efv-conversational-ai-008, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-004, efv-rtc-voice-009, efv-rtc-voice-010, efv-rtc-voice-003, efv-routing-001, efv-routing-002, efv-routing-003, efv-cti-crm-005, efv-core-objects-001, efv-core-objects-003, efv-security-001 # AI Voice Bot with Human Handoff ## Customer challenge IVR menus impose a rigid, menu-driven experience that frustrates callers and limits deflection to narrow, scripted scenarios. When callers say "I want to check my claim status" and are presented with "Press 1 for billing, Press 2 for claims…", containment rates are poor and CSAT suffers. Deploying a voice AI bot that genuinely understands natural speech has been difficult: traditional NLU-based voice bots are expensive to train, degrade quickly as product information changes, and fail silently when handed off to agents without context. ## ExpertFlow's approach ExpertFlow's voice AI layer uses Jambonz for voice application logic and integrates with configurable speech engines (including ElevenLabs for voice synthesis) and LLM backends for natural language understanding. Call forking via ExpertFlow's RTC layer sends audio to the AI layer in real time without touching the SIP signaling path — the call remains stable even if the AI layer experiences latency. The bot retrieves answers from the customer's knowledge base via RAG, so policy and product information is always current without model retraining. When the bot determines escalation is needed — by intent, sentiment, or explicit caller request — it triggers a structured handoff to the routing layer. The agent receives the full bot transcript, identified intent, and sentiment score at the moment of connection. No context is re-asked. ## Why ExpertFlow wins here Unlike cloud CCaaS platforms that bundle a proprietary voice bot with limited integration depth, ExpertFlow's voice AI is architecturally decoupled: the dialog layer, the speech engine, and the LLM are independently configurable. Customers can run a local speech engine on-premise for data residency compliance while using a cloud LLM for reasoning — or run everything locally. The handoff path uses the same routing and conversation model as human-to-human transfers, so context carries naturally. ## Typical deployment context Contact centres with high inbound call volume where a significant fraction of calls are routine and repeatable. Regulated industries (insurance, banking, healthcare) where data residency constraints preclude sending audio to cloud-only AI services benefit most from ExpertFlow's deployment flexibility. Often deployed alongside the chat bot pattern (efv-sol-003) to provide consistent AI self-service across channels. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Microsoft Dynamics 365 Embedded Agent Desktop ID: efv-sol-005 Target segments: financial-services, professional-services, healthcare, manufacturing, microsoft-dynamics-customers Description: Organisations running Microsoft Dynamics 365 as their CRM can embed the full ExpertFlow agent experience directly inside Dynamics — voice, chat, and email controls appear as a native panel within the Dynamics interface. Agents handle every customer interaction without switching applications. Each conversation is automatically linked to the Dynamics contact and account record; cases are created from conversation metadata. Click-to-dial initiates calls from within Dynamics. AI Assist surfaces suggested responses and knowledge articles in context during the interaction. Canonical use case: A professional services firm with 200 Dynamics 365 users in customer-facing roles wants their agents to handle inbound calls and chats without a separate softphone or contact centre console. ExpertFlow's Dynamics panel gives them telephony, queue management, and interaction history inside Dynamics, with every call automatically logged against the relevant account. Composed of features: efv-cti-crm-001, efv-cti-crm-005, efv-cti-crm-006, efv-cti-crm-007, efv-cti-crm-008, efv-cti-crm-009, efv-cti-crm-013, efv-cti-crm-014, efv-cti-crm-015, efv-cti-crm-016, efv-routing-001, efv-routing-002, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-004, efv-security-001, efv-security-003 # Microsoft Dynamics 365 Embedded Agent Desktop ## Customer challenge Organisations that have standardised on Microsoft Dynamics 365 for customer relationship management face a fundamental workflow problem in the contact centre: agents must operate a separate telephony or CCaaS application alongside Dynamics. The result is constant context-switching, missed screen pops, and manual logging of call dispositions. Automation is limited by the integration depth available through packaged connectors, which typically surface only caller ID and basic activity records. ## ExpertFlow's approach ExpertFlow integrates with Microsoft Dynamics 365 using the Dynamics Channel Integration Framework (CIF) to embed a full-featured agent panel directly inside the Dynamics UI. The panel delivers: - Voice controls (answer, hold, transfer, conference, end) via WebRTC softphone - Chat and digital channel handling in the same panel - Automatic screen pop matched on phone number or customer identity - Real-time queue status and agent state controls - AI Assist with suggested responses drawn from the Dynamics knowledge base - Automatic activity creation and case linkage on call end Every conversation record in ExpertFlow is linked bidirectionally to the Dynamics contact and case, enabling full interaction history from within Dynamics without opening a second system. ## Why ExpertFlow wins here ExpertFlow's CRM-native embedding approach is deeper than adapter-based connectors. Rather than a browser extension or CTI bar overlaid on Dynamics, ExpertFlow uses Dynamics' own extension framework — meaning the panel behaves as a native Dynamics component, respects Dynamics RBAC, and participates in Dynamics workflows. Open Agent State API means enterprise customers can build custom Dynamics automations triggered by contact centre events, without being constrained by a packaged connector. ## Typical deployment context Microsoft-stack enterprises (Azure AD, Teams, Dynamics 365) typically with 50–500 agent seats in customer service, inside sales, or field service operations. Often deploying alongside a Teams direct routing or existing SIP PBX infrastructure. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Salesforce Service Cloud Embedded Agent Desktop ID: efv-sol-006 Target segments: technology, financial-services, retail, manufacturing, salesforce-customers Description: Salesforce Service Cloud customers can run ExpertFlow's contact centre capabilities directly inside the Salesforce interface via an Open CTI-compatible embedded panel. Voice, chat, and digital channel controls appear within Salesforce Lightning without requiring agents to open a separate application. Calls and conversations are automatically linked to Salesforce contacts and cases; screen pop matches the caller to an existing record on connection. The integration is available through the Salesforce AppExchange, accelerating procurement and deployment. AI Assist surfaces relevant Salesforce knowledge articles during live interactions. Canonical use case: A B2B software company with 120 support agents running Salesforce Service Cloud wants to replace a standalone CCaaS tool that requires agents to manage contacts in two systems. ExpertFlow's Salesforce panel embeds telephony and chat handling inside Service Cloud, auto-creates cases from calls, and surfaces knowledge base articles via AI Assist — without migrating away from Salesforce as the system of record. Composed of features: efv-cti-crm-002, efv-cti-crm-005, efv-cti-crm-006, efv-cti-crm-007, efv-cti-crm-008, efv-cti-crm-009, efv-cti-crm-013, efv-cti-crm-014, efv-cti-crm-015, efv-cti-crm-016, efv-cti-crm-017, efv-routing-001, efv-routing-002, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-004, efv-security-001, efv-security-003 # Salesforce Service Cloud Embedded Agent Desktop ## Customer challenge Salesforce Service Cloud is the CRM of record for many enterprise customer service operations. However, Salesforce's native telephony (Service Cloud Voice) requires Amazon Connect as the underlying telephony provider and is not available or economical in all geographies. Third-party CCaaS tools integrate with Salesforce via Open CTI but typically surface only a narrow call-control bar with limited data depth — case auto-creation and interaction history linking require additional configuration or custom development. The result is agents working in Salesforce for case management while using a separate system for contact centre operations, with partial or manual data synchronisation between them. ## ExpertFlow's approach ExpertFlow integrates with Salesforce using the Salesforce Open CTI standard, delivering a full-featured agent panel within the Salesforce Lightning interface. The panel provides: - Voice controls via WebRTC softphone embedded in the Salesforce utility bar - Chat, email, and digital channel controls in the same panel - Automatic screen pop matching caller to Salesforce contact on connection - Auto-creation of Salesforce cases from conversation metadata on call end - Bidirectional interaction history: Salesforce shows ExpertFlow conversation records - AI Assist surfacing relevant Salesforce Knowledge articles during calls - Supervisor monitoring and queue state visibility ExpertFlow is available on the Salesforce AppExchange, enabling procurement through established Salesforce purchasing channels. ## Why ExpertFlow wins here ExpertFlow offers Salesforce customers a contact centre that works in their geography and on their infrastructure — cloud or on-premise — without requiring Amazon Connect or a US-hosted SIP path. For markets where Salesforce Service Cloud Voice is unavailable or cost-prohibitive, ExpertFlow provides equivalent embedded telephony without compromising Salesforce as the system of record. Open API means custom Salesforce flows can be triggered by contact centre events, beyond what packaged connectors expose. ## Typical deployment context Salesforce Service Cloud customers with 30–500 agent seats. Common in technology companies, professional services, and financial services where Salesforce is the primary CRM and data governance requirements preclude using US-hosted voice routing. Often deployed with existing SIP trunks that the customer wants to retain. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: SAP and Zoho CRM Contact Centre Integration ID: efv-sol-007 Target segments: manufacturing, distribution, mid-market, sap-customers, zoho-customers Description: Organisations running SAP Customer Experience or Zoho CRM can connect ExpertFlow to their CRM via dedicated integration connectors and the open Agent State API. Agents handle voice and digital contacts from an embedded or alongside-panel desktop linked to their CRM records. Screen pop, interaction history, and click-to-dial are available for both platforms. The Generic Agent Desktop API enables organisations with customised SAP or Zoho deployments to build tailored integration depth beyond the standard connector, without dependence on a marketplace connector release cycle. Canonical use case: A mid-market manufacturing firm using Zoho CRM for their 60-agent inside sales and support team wants telephony integrated with CRM records. Agents see the account and contact record when a call arrives, log call notes inside Zoho, and initiate outbound calls by clicking a phone number in the CRM. No separate softphone application is required. Composed of features: efv-cti-crm-003, efv-cti-crm-004, efv-cti-crm-005, efv-cti-crm-006, efv-cti-crm-007, efv-cti-crm-008, efv-cti-crm-009, efv-cti-crm-014, efv-cti-crm-016, efv-routing-001, efv-routing-002, efv-routing-003, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-004, efv-security-001 # SAP and Zoho CRM Contact Centre Integration ## Customer challenge SAP Customer Experience (C4C, SAP CRM) and Zoho CRM users in customer-facing roles face a persistent integration gap: their CRM holds the authoritative customer record, but their contact centre telephony runs on a separate platform with no real-time data exchange. Agents manually search the CRM after answering a call; call logs are entered manually or not at all. The integration connectors that do exist are often shallow — passing caller ID but not returning interaction history or enabling in-CRM call controls. ## ExpertFlow's approach ExpertFlow provides dedicated integration connectors for SAP Customer Experience and Zoho CRM, surfacing telephony and digital channel controls inside or alongside the CRM interface. Core capabilities include screen pop on call arrival, full interaction history linked to the CRM record, click-to-dial from CRM contact and account pages, and automatic call logging on wrap-up. For organisations with customised SAP or Zoho deployments, ExpertFlow's open Agent State API and CRM Conversation Linking API allow development teams to build deeper integration — triggering CRM workflows from conversation events, syncing custom objects, or embedding the agent controls inside proprietary CRM views — without waiting for a connector update. ## Why ExpertFlow wins here ExpertFlow treats SAP and Zoho as first-class CRM targets rather than secondary integrations. The open API model means integration depth is not constrained by what a packaged connector exposes. Organisations with bespoke CRM configurations — common in SAP environments — can achieve the same level of embedded integration as Dynamics or Salesforce customers. This matters particularly in markets (MENA, South Asia) where SAP deployments are common and hosted CCaaS with deep SAP integration is limited. ## Typical deployment context Mid-to-large enterprises with SAP CX for service management, or SME-to-mid-market companies using Zoho CRM across inside sales and customer support. Typical seat range 30–300 agents. Often on-premise SAP installations where data leaving the network is a compliance concern — ExpertFlow's on-premise deployment option is relevant here. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Cisco CCE / CCX Migration to ExpertFlow ID: efv-sol-008 Target segments: government, financial-services, healthcare, telco, cisco-cce-customers, cisco-ccx-customers Description: Organisations running Cisco Unified Contact Center Enterprise (CCE) or Contact Center Express (CCX) face escalating maintenance costs and a product roadmap that increasingly points toward Webex Contact Center. ExpertFlow provides a co-existence and migration path: ExpertFlow can run alongside existing Cisco CCE/CCX, taking over agent desktop, routing, and digital channels while CUCM telephony infrastructure remains in place. Migration can proceed in phases — by agent group, channel, or geography — without a cutover weekend. Agents use modern browser-based tooling while Cisco voice infrastructure continues to handle PSTN connectivity. Canonical use case: A government agency running Cisco CCE with 400 agents needs to modernise the agent desktop, add chat and AI capabilities, and reduce Cisco maintenance costs — but cannot afford a full platform cutover. ExpertFlow deploys alongside CCE: agents move to the ExpertFlow desktop in groups while CUCM handles SIP. The agency gains omnichannel and AI capabilities immediately, with a multi-year Cisco retirement plan. Composed of features: efv-deployment-005, efv-deployment-001, efv-deployment-002, efv-cti-crm-010, efv-cti-crm-011, efv-cti-crm-012, efv-cti-crm-005, efv-cti-crm-007, efv-routing-001, efv-routing-002, efv-routing-003, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-rtc-voice-005, efv-core-objects-001, efv-core-objects-003, efv-security-001 # Cisco CCE / CCX Migration to ExpertFlow ## Customer challenge Cisco CCE and CCX customers face a compound problem: the platforms are mature and expensive to maintain, Cisco's roadmap is consolidating onto Webex Contact Center (a US-hosted cloud service), and the path to any modern capability (AI bots, digital channels, CRM embedding) requires either expensive Cisco professional services or a disruptive full platform migration. A big-bang cutover carries execution risk that many regulated or large-scale contact centres cannot accept. Yet staying on CCE/CCX means falling behind on agent experience and digital channel capabilities, with rising support costs on ageing infrastructure. ## ExpertFlow's approach ExpertFlow's Cisco CCE co-existence model allows ExpertFlow to run alongside — not instead of — existing Cisco infrastructure during the transition period. The approach: - CUCM/SIP voice infrastructure remains in place; ExpertFlow connects via SIP - Cisco CCE/CCX continues to handle PSTN routing during co-existence - ExpertFlow takes over the agent desktop for migrated agent groups - Digital channels (chat, email, social) are handed to ExpertFlow immediately - Skills-based routing in ExpertFlow runs in parallel with CCE routing, migrating routing logic incrementally - IVR and self-service are moved to ExpertFlow at a pace determined by the customer This model enables a phased migration: the customer gains new capabilities immediately while retiring Cisco components at a controlled pace. ## Why ExpertFlow wins here Unlike Webex Contact Center, which requires full migration to Cisco's cloud and introduces US-hosted SIP routing, ExpertFlow maintains the customer's existing on-premise infrastructure investment. Customers in regulated industries or markets with data sovereignty requirements cannot route voice through a US cloud POP — ExpertFlow's edge call-control architecture keeps signaling and media on the customer's network. The open architecture means the customer is not simply trading one vendor lock-in for another. ## Typical deployment context Cisco CCE customers with 100–2 000 agent seats. Common in government, healthcare, and financial services where data residency or procurement rules prevent moving to US-hosted cloud. On-premise Kubernetes deployment is typical. Co-existence period may run 12–36 months before full Cisco retirement. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Cloud-Native Contact Center Deployment (AWS / Azure) ID: efv-sol-009 Target segments: financial-services, technology, e-commerce, healthcare, digital-native Description: Organisations that prefer cloud hosting for operational simplicity can deploy ExpertFlow on AWS or Azure using a fully Kubernetes-native architecture. All ExpertFlow components run as containers on customer-managed or managed Kubernetes clusters, enabling elasticity, automated scaling, and cloud-native operational tooling. High availability across availability zones is built into the deployment model. ExpertFlow's cloud deployment is not a SaaS shared-tenant offering — each customer runs their own isolated instance, retaining full control over data residency within their chosen cloud region. Canonical use case: A digital-native financial services firm wants a contact centre on their existing AWS tenancy in the EU-West region for data residency compliance. They need Kubernetes-native deployment they can manage through their existing GitOps pipeline, with high availability across two availability zones and automatic failover. Composed of features: efv-deployment-001, efv-deployment-003, efv-deployment-004, efv-deployment-006, efv-deployment-007, efv-security-001, efv-security-003, efv-security-005, efv-security-007, efv-routing-001, efv-routing-002, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-006 # Cloud-Native Contact Center Deployment (AWS / Azure) ## Customer challenge Organisations operating in cloud-first environments want to run their contact centre on the same cloud platform and Kubernetes infrastructure as the rest of their applications. Proprietary CCaaS platforms provide operational simplicity but at the cost of shared tenancy, limited data residency control, and infrastructure that cannot be managed through standard cloud operations tooling (IaC, GitOps, cloud-native monitoring). The alternative — on-premise deployment — requires capital infrastructure and operational staff that many cloud-native organisations have deliberately eliminated. ## ExpertFlow's approach ExpertFlow is built Kubernetes-native from the ground up. Every component is containerised and deployable on standard Kubernetes distributions including Amazon EKS, Azure AKS, and managed Kubernetes offerings. Deployment is defined as Kubernetes manifests and Helm charts, enabling management through standard cloud engineering pipelines. Key cloud deployment characteristics: - Single-tenant: each customer operates an isolated ExpertFlow instance in their own cloud account, with no shared data layer - Regionally deployed: choose the cloud region; all data stays within it - Horizontally scalable: add capacity by scaling Kubernetes node pools - High availability: active-active configuration across availability zones - Cloud-native monitoring: metrics exposed to Prometheus/Grafana; compatible with CloudWatch, Azure Monitor ## Why ExpertFlow wins here ExpertFlow's cloud deployment is single-tenant and customer-controlled — unlike SaaS CCaaS platforms where data residency cannot be guaranteed and shared infrastructure is a compliance risk. Unlike platforms that offer "on-premise" as a legacy VM-based installer, ExpertFlow's Kubernetes architecture behaves identically in cloud and on-premise environments, so operational runbooks and tooling are consistent. Cloud deployment does not mean surrendering control. ## Typical deployment context Cloud-first organisations that have standardised on AWS or Azure for all workloads. Often with an existing Kubernetes operations team and GitOps toolchain. Financial services or healthcare customers with strict data residency requirements that preclude shared-tenant CCaaS but have exited data centre operations. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: On-Premise Contact Center for Regulated Industries ID: efv-sol-010 Target segments: financial-services, banking, government, healthcare, defence Description: Regulated industries — banking, healthcare, government, defence — often cannot send customer voice or conversation data to a cloud provider. ExpertFlow deploys fully on-premise on Kubernetes, with no call home, no data egress, and no dependency on external cloud services for core contact centre operation. Compliance modes for PCI-DSS, HIPAA, GDPR, and SOC-2 are built in. SSO integrates with on-premise Active Directory and LDAP. On-premise deployment does not mean capability compromise — agents get the same omnichannel desktop, skills-based routing, and AI features as cloud deployments, running entirely within the customer's data centre. Canonical use case: A central bank with 500 internal and customer-facing contact centre agents has a regulatory mandate that all voice recordings and customer data must remain in their own data centre. They need a modern contact centre with CRM integration, supervisor monitoring, and AI-assisted responses — all running on their on-premise Kubernetes cluster with no cloud dependencies. Composed of features: efv-deployment-001, efv-deployment-002, efv-deployment-006, efv-deployment-009, efv-security-001, efv-security-002, efv-security-003, efv-security-004, efv-security-005, efv-security-006, efv-security-008, efv-security-009, efv-routing-001, efv-routing-002, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-006 # On-Premise Contact Center for Regulated Industries ## Customer challenge Banks, hospitals, government agencies, and defence contractors face data residency and regulatory constraints that many modern CCaaS platforms cannot satisfy. Regulations such as PCI-DSS (payment card data), HIPAA (healthcare), and national data sovereignty laws require that voice recordings, conversation transcripts, and customer identity data remain within controlled infrastructure — not a shared cloud. Cloud-only CCaaS vendors either cannot meet this requirement or require expensive private-cloud agreements that still route signaling through vendor-controlled infrastructure. On-premise contact centre alternatives are often legacy systems with VM-based installers, outdated agent tooling, and limited support for modern AI and digital channels. ## ExpertFlow's approach ExpertFlow runs fully on-premise on Kubernetes — deployed on the customer's own servers in their own data centre. There is no dependency on ExpertFlow-operated cloud infrastructure for call handling, routing, AI processing, or recording storage. The platform includes: - Kubernetes-native deployment manageable through the customer's own GitOps toolchain - SSO integration with on-premise Active Directory, LDAP, and Keycloak - PCI-DSS compliance mode: call recording pause/resume, cardholder data masking - HIPAA compliance mode: audit logging, data access controls, PHI handling - GDPR controls: data subject access, retention policies, right to erasure - SOC-2 audit trail for all administrative and agent actions - End-to-end encryption of recordings and conversation data at rest and in transit - High availability within the data centre — no single point of failure Omnichannel, AI, and CRM integration capabilities are fully available in the on-premise deployment — the same feature set as cloud. ## Why ExpertFlow wins here ExpertFlow's on-premise deployment is Kubernetes-native, not a legacy VM installer. This means the operational model — Helm charts, GitOps, container monitoring — is the same as cloud-native deployments, giving regulated organisations a modern operational experience without sending data outside their perimeter. Competitors offering on-premise options typically do so through legacy VM appliances with separate feature roadmaps; ExpertFlow maintains a single codebase across deployment models, so on-premise customers receive the same capabilities as cloud customers. ## Typical deployment context Regulated enterprises with 100–2 000 agent seats. Typically running their own data centre or private cloud (VMware, OpenStack, or bare-metal Kubernetes). Active Directory environment. Strong preference for open standards (Keycloak, OAuth2) over proprietary SSO. Often upgrading from legacy Cisco CCE or on-premise Avaya/Genesys. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Outbound Campaign Management ID: efv-sol-011 Target segments: financial-services, collections, insurance, healthcare, retail Description: Contact centres running outbound programmes — collections, renewals, appointment reminders, sales development — need campaign management tooling that lets supervisors define contact lists, set calling schedules, and control dial pacing within compliance boundaries (GDPR, TCPA, opt-out management). ExpertFlow's outbound pattern provides campaign management, scheduled outbound routing, and blended inbound/outbound agent handling. Agents use the same desktop for both inbound and outbound interactions; supervisors monitor live campaign metrics and adjust pace in real time. Canonical use case: A debt collection agency runs daily outbound campaigns against 50 000 accounts using 120 agents. Campaign supervisors need to load contact lists, schedule calling windows per timezone, enforce opt-out suppression, and monitor per-agent and per-campaign conversion metrics — all within GDPR constraints. Composed of features: efv-core-objects-005, efv-core-objects-009, efv-core-objects-008, efv-core-objects-001, efv-core-objects-003, efv-routing-004, efv-routing-006, efv-routing-007, efv-routing-002, efv-routing-010, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-cti-crm-005, efv-cti-crm-007, efv-conversational-ai-007, efv-conversational-ai-008, efv-security-001, efv-security-006 # Outbound Campaign Management ## Customer challenge Outbound contact centre operations require a different operational model from inbound: supervisors must manage contact lists, define calling schedules, control dial pacing, enforce regulatory suppression lists, and measure campaign performance in real time. Many inbound-first contact centre platforms offer outbound as an afterthought — basic preview dialling only — requiring organisations to run a separate outbound dialler platform alongside their inbound system, with separate agent populations and duplicated reporting. Compliance adds further complexity: GDPR requires opt-out enforcement and data retention controls; TCPA imposes calling time restrictions; opt-out lists must be applied in real time before any dial attempt. ## ExpertFlow's approach ExpertFlow's campaign management layer allows supervisors to define outbound campaigns against client lists maintained in ExpertFlow's core objects layer: - Contact lists uploaded or CRM-synced, with deduplication and suppression - Campaign scheduling: define calling windows per timezone and per campaign - Dial pace control: preview and progressive dialling modes - Real-time opt-out enforcement: suppression list checked before each dial attempt - GDPR controls: consent tracking, data retention periods per campaign - Blended agents: agents handle inbound calls during outbound campaign quiet periods without supervisor intervention - Campaign analytics: connection rate, conversion rate, average handle time by campaign and agent Every outbound conversation is recorded as a unified conversation object, linked to the client record and the originating campaign. ## Why ExpertFlow wins here ExpertFlow's unified conversation model treats outbound calls identically to inbound contacts — same routing, same recording, same CRM linking, same AI assist for agents. Organisations do not need a separate dialler product; outbound campaigns run on the same platform as inbound queues, enabling truly blended agent pools with no system-switching overhead. GDPR compliance controls are built into the campaign layer, not bolted on, which matters in regulated markets. ## Typical deployment context Contact centres with 50–500 agents running outbound programmes alongside inbound service queues. Common in financial services (collections, renewals), insurance (policy review), healthcare (appointment reminders), and retail (loyalty programmes). On-premise or cloud deployment, often with a compliance requirement for opt-out audit trails. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- Solution Pattern: Hybrid Cloud and On-Premise Deployment ID: efv-sol-012 Target segments: financial-services, banking, government, multinational-enterprise, telco Description: Large enterprises and regulated organisations often need contact centre workloads split across on-premise infrastructure and cloud: voice media and recordings stay on-premise for compliance while cloud handles burst capacity, disaster recovery, or remote agent populations. ExpertFlow's Kubernetes-native architecture makes hybrid deployment a first-class topology — both environments run identical platform code, share a unified routing and conversation layer, and are managed through the same operational tooling. Agents at on-premise sites and remote cloud agents work from the same desktop with no capability difference. Canonical use case: A multinational bank has a main contact centre on-premise in its home country for data residency compliance, and remote overflow agents in another country handled through an Azure cloud deployment. Both populations must appear in the same routing pool, share the same queue configuration, and report through the same supervisor dashboard — with recordings for the on-premise population stored locally and cloud recordings in a customer-owned Azure storage account. Composed of features: efv-deployment-001, efv-deployment-002, efv-deployment-003, efv-deployment-004, efv-deployment-006, efv-deployment-010, efv-security-001, efv-security-002, efv-security-003, efv-security-005, efv-security-006, efv-routing-001, efv-routing-002, efv-routing-011, efv-rtc-voice-001, efv-rtc-voice-002, efv-rtc-voice-003, efv-core-objects-001, efv-core-objects-006 # Hybrid Cloud and On-Premise Deployment ## Customer challenge Enterprise contact centres rarely fit neatly into a "fully cloud" or "fully on-premise" category. Regulatory requirements constrain what can go to cloud; operational flexibility and disaster recovery requirements push toward cloud-capable architectures. The result is often a hybrid reality: core infrastructure on-premise, overflow or remote populations in cloud, with two separate platforms that cannot share routing pools, queue configuration, or reporting. Managing two contact centre platforms — one on-premise, one cloud — doubles operational overhead and creates capability gaps: cloud-only features are unavailable on-premise; on-premise integrations cannot be replicated in cloud without custom work. ## ExpertFlow's approach ExpertFlow's hybrid deployment model runs identical platform components across on-premise and cloud environments, connected by a shared routing and conversation layer: - On-premise Kubernetes cluster handles data-residency-sensitive workloads: voice media processing, recording storage, and data-residency-bound agent populations - Cloud Kubernetes cluster (AWS EKS, Azure AKS) handles burst capacity, DR failover, or geographically remote agent groups - Unified routing: all agent populations — on-premise and cloud — appear in a single routing pool; queue configuration is shared - Single supervisor view: wallboards and reporting span both environments - Recordings stored per-environment: on-premise recordings in local storage, cloud recordings in customer-owned cloud storage bucket - Configuration management via GitOps: the same Helm chart values drive both environments, with environment-specific overrides ## Why ExpertFlow wins here ExpertFlow's architecture is infrastructure-agnostic because it is Kubernetes-native, not VM-packaged. Running the same containers on two Kubernetes clusters is a supported, tested topology — not a bespoke integration. Competitors with separate cloud and on-premise products cannot achieve true operational parity across environments: cloud products have features the on-premise version lacks, and integrating them requires custom bridging. ExpertFlow's single codebase across deployment topologies means feature parity is structural, not an aspiration. ## Typical deployment context Multinational enterprises with regulatory requirements in at least one jurisdiction that require on-premise media handling, alongside remote workforce populations or cloud-first subsidiaries. Common in banking, insurance, and government agencies operating across multiple countries. Seat ranges typically 200–3 000 across both environments. - [x] Confirm all features in `features_included` exist in the catalog (forward refs) - [x] Set `decomposition_status: clean` once Window 1 features are committed - [x] Derive `primary_axioms` from features (run bmad-catalog-intake) --- ======================================================================== CANON AXIOMS ======================================================================== Canon Axiom: Skills-Based Routing with Real-Time Agent State ID: axiom-001 Domain: routing Claim: "ExpertFlow routes contacts by scoring agents on real-time skills and live state" # Skills-Based Routing with Real-Time Agent State ## The choice ExpertFlow made ExpertFlow matches each incoming contact to an agent by evaluating the full set of agent skills against the contact's requirements at the moment of dispatch, using live agent state as the eligibility gate. An agent who is on a call, in after-call work, or in a non-ready state is excluded from consideration in real time. The routing decision is made fresh at each dispatch event. ## The alternative (who made it and why it exists) Rule-based queue assignment systems — common in legacy ACDs and simpler cloud contact centres — assign contacts to named queues and dispatch on a first-in, first-out basis within each queue. Agent "skills" are represented as queue memberships: an agent belongs to "Billing Queue" or "Technical Queue" but the system does not score agents against contact requirements or dynamically consider cross-queue capacity. Agent state is polled on a fixed cycle (typically 5–30 seconds), meaning an agent who became available 10 seconds ago is not yet visible to the routing engine. This approach is simpler to configure and adequate for low-volume, single-skill contact centres, which is why it was the industry standard for two decades and why many hosted CCaaS platforms still use it as their default model. ## The scenario where our choice wins Customers with multi-skill agent populations — common in financial services, healthcare, and enterprise contact centres — where a significant percentage of contacts require more than one agent skill. In a queue-per-skill model, agents belong to multiple queues and receive contacts from each independently, leading to unbalanced workload and agents taking calls outside their primary skill when their primary queue is quiet. Also: high-volume contact centres where polling-based agent state introduces meaningful assignment lag — at 1 000 contacts per hour, a 15-second polling cycle means agents sit idle waiting for the system to "discover" they're available. ## The one-sentence axiom claim > "ExpertFlow routes contacts by scoring agents on real-time skills and live state > at the moment of dispatch — unlike queue-membership models that poll state on a > fixed cycle — which means multi-skill agents are used optimally and assignment > lag is eliminated in high-volume contact centres." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE | Queue-based routing with skill groups; state polled via CTI heartbeat | Multi-skill agent optimisation; assignment latency at scale | | Genesys Cloud | Skills-based routing available, but default templates use queue-per-channel | Configuration complexity vs. ExpertFlow's unified skills model | | Amazon Connect | Contact flows with queue routing; skills-based routing requires custom Lambda | Operational simplicity for multi-skill contact centres | | Five9 | Queue-based with skill assignment; real-time state via agent desktop heartbeat | Assignment lag; cross-queue balancing requires supervisor intervention | --- Canon Axiom: Event-Driven Routing Commitment Gate ID: axiom-002 Domain: routing Claim: "ExpertFlow fires routing dispatch the instant an agent availability event fires —" # Event-Driven Routing Commitment Gate ## The choice ExpertFlow made ExpertFlow commits a contact to an agent the moment an agent state-change event signals availability — not on a polling cycle. The routing engine subscribes to agent state events and fires the dispatch decision immediately when the conditions for a match are satisfied. There is no background scheduler that periodically sweeps the waiting queue; the gate opens on the event. ## The alternative (who made it and why it exists) Legacy ACD platforms and many first-generation cloud contact centres use a polling model: a scheduler process runs every N seconds (typically 5–30 seconds), reads current agent state from a state table, and assigns any waiting contacts to newly available agents. This design is simpler to implement on relational database backends and was the standard model before event-streaming infrastructure became widely available. Some platforms hybridise: they poll at a short interval (1–2 seconds) and call this "near real-time." ## The scenario where our choice wins High-volume contact centres where assignment lag has a measurable impact on service levels. At 600 contacts per hour (typical for a 50-agent contact centre), each second of assignment lag adds roughly 10 minutes of cumulative unnecessary wait time per hour across the entire queue. In collections, appointment scheduling, or emergency dispatch scenarios where every second matters, polling-based commitment introduces latency that degrades both SLA and customer experience. Also relevant in blended outbound/inbound environments: when an agent completes an outbound call and is immediately eligible for an inbound contact, an event- driven system connects the next contact within milliseconds; a polling system waits for the next sweep cycle. ## The one-sentence axiom claim > "ExpertFlow fires routing dispatch the instant an agent availability event fires — > unlike polling-based ACDs that assign contacts on fixed intervals — which means > queue wait time is minimised at scale and blended agent transitions are seamless." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE | CTI heartbeat-based state polling; assignment computed in ICM on cycle | Assignment latency at high volume; supervisor must manually intervene on lag | | Avaya CMS | Polling-based CMS reporting and routing; near-real-time at 5s intervals | Blended agent transitions; queue drain speed under burst traffic | | Amazon Connect | Lambda-triggered routing on contact arrival; agent state via polling | Agent availability responsiveness; complex blended scenarios | | Genesys Engage | Routing server polling; configurable interval (default 2s) | Sub-second assignment in time-sensitive contact centre operations | --- Canon Axiom: Edge Call Control ID: axiom-003 Domain: rtc-voice Claim: "ExpertFlow runs call control at the customer's own network edge — unlike" # Edge Call Control ## The choice ExpertFlow made Call control logic in ExpertFlow runs at the customer's network edge — on the customer's on-premise servers or within the customer's cloud tenancy — not in an ExpertFlow-operated cloud POP. SIP signaling and voice media travel between the PSTN, the edge call-control layer, and the agent on the local network. No signaling or media traverses an ExpertFlow-operated intermediary between the customer's network and the public telephone network. ## The alternative (who made it and why it exists) Cloud-first CCaaS platforms (Genesys Cloud, Amazon Connect, Twilio Flex, Webex Contact Center) route all SIP signaling and often voice media through geographically fixed cloud POPs (Points of Presence). This approach centralises call control, simplifies platform operations for the vendor, enables rapid feature deployment, and removes the need for on-premise voice infrastructure. It works well for customers with reliable, low-latency internet connectivity to the vendor's cloud region. ## The scenario where our choice wins Customers operating in geographies where cloud POP latency is high or unreliable (MENA, South Asia, Sub-Saharan Africa) or across multiple sites connected by WAN links that may degrade. When a cloud POP is in a US or European data centre and the customer's agents are in Pakistan or Saudi Arabia, signaling round-trips add 150–400ms latency to each call leg, degrading audio quality and increasing post-dial delay to unacceptable levels. Also: customers with data sovereignty requirements that prohibit voice signaling or recordings traversing infrastructure outside their jurisdiction. When call control runs at the edge, the customer's regulatory perimeter is preserved. ## The one-sentence axiom claim > "ExpertFlow runs call control at the customer's own network edge — unlike > cloud-POP CCaaS platforms where signaling traverses vendor infrastructure — > which means audio latency is bounded by the local network and data sovereignty > is preserved regardless of internet path quality." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | US/EU cloud POPs for all SIP signaling; media servers in cloud | High-latency geographies (MENA, South Asia); data sovereignty requirements | | Amazon Connect | AWS region-based call control; media traverses AWS | Same as above; also: customers not permitted to use US-hosted infrastructure | | Webex Contact Center | Cisco-operated cloud POPs; on-premise option available but limited | Latency-sensitive deployments; Cisco customers in non-US regions | | Twilio Flex | Global edge network but control plane is cloud-hosted | Data sovereignty; regulated industries requiring on-premise signaling | | Five9 | US-hosted cloud POP for all call control | MENA/APAC/South Asia deployments; government and banking compliance | --- Canon Axiom: WebRTC-Native Voice via LiveKit ID: axiom-004 Domain: rtc-voice Claim: "ExpertFlow delivers agent audio natively via WebRTC in the browser — unlike" # WebRTC-Native Voice via LiveKit ## The choice ExpertFlow made Agent audio in ExpertFlow is handled natively via WebRTC — no SIP softphone installation, no desk phone provisioning, and no browser plugin required. The agent's browser connects directly to the voice media layer using WebRTC, providing a full-featured softphone experience in any modern browser. The WebRTC media layer uses LiveKit as the selective forwarding unit (SFU), providing scalable, low-latency media handling without requiring a proprietary media server appliance. ## The alternative (who made it and why it exists) Traditional contact centre platforms — and many of today's cloud platforms — use SIP softphone clients (standalone applications or browser plugins) as the agent audio endpoint. The SIP softphone establishes a SIP dialog with the call control layer; voice media flows over RTP between the softphone and the media server. This approach is well-understood, compatible with desk phones and SIP hardware endpoints, and preferred in environments where agents need to work from managed desktop environments with controlled software installations. Some platforms offer WebRTC but layer it on top of a SIP gateway — the browser speaks WebRTC to a gateway that translates to SIP internally. This introduces an additional transcoding hop and the latency and complexity that comes with it. ## The scenario where our choice wins Remote and distributed agent workforces where installing and maintaining softphone applications on agent devices is operationally costly or infeasible. Agents who work from shared terminals, thin clients, or unmanaged personal devices cannot install softphone applications but can use a browser. Browser-based WebRTC also simplifies security review: no desktop application means no additional attack surface, no software update cycle, and no VPN requirement for media. Also: CRM-embedded agent desktop deployments (Dynamics, Salesforce) where the agent desktop is a browser panel inside the CRM — native WebRTC means audio works inside the same browser session as the CRM without a separate softphone window. ## The one-sentence axiom claim > "ExpertFlow delivers agent audio natively via WebRTC in the browser — unlike > SIP softphone or gateway-bridged approaches that require client installation > or transcoding hops — which means remote agents work from any browser with > no software to install and CRM-embedded audio runs inside the same browser > session." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE / Finesse | JTAPI softphone or Cisco IP Phone required; browser-based via Finesse with SIP gateway | Remote agents on unmanaged devices; thin client / VDI environments | | Avaya | Avaya One-X Agent softphone required for full feature set | Same as above; also: softphone update management overhead | | Genesys Cloud | WebRTC supported but via SIP gateway translation internally | Transcoding latency; ExpertFlow's direct WebRTC path is lower latency | | Five9 | Browser softphone available; WebRTC via SIP gateway bridge | Transcoding hop; media quality in embedded desktop scenarios | --- Canon Axiom: CRM-Native Embedding vs. Separate Agent Desktop ID: axiom-005 Domain: cti-crm Claim: "ExpertFlow embeds contact centre controls natively inside the CRM using the" # CRM-Native Embedding vs. Separate Agent Desktop ## The choice ExpertFlow made ExpertFlow embeds contact centre controls directly inside the CRM interface using the CRM's own extension framework — Dynamics Channel Integration Framework for Microsoft Dynamics, Open CTI for Salesforce. The agent's telephony and digital channel controls appear as a native panel within the CRM. There is no separate contact centre application for the agent to open, switch to, or maintain. The CRM is the agent's single interface; ExpertFlow provides the contact centre layer within it. ## The alternative (who made it and why it exists) The traditional model — and still the default in many enterprise contact centre deployments — runs the contact centre platform as a standalone application (a desktop softphone, a thick-client ACD agent interface, or a separate browser tab/window) and connects it to the CRM via a CTI integration. The CTI integration typically handles screen pop: when a call arrives, the ACD sends the caller's phone number to the CRM, which opens the matching contact record. The agent operates both applications simultaneously. This model predates modern browser-based CRM extension frameworks. It was the only available architecture for two decades and remains common because many installed systems were built on it. Some vendors have adopted a hybrid: a CTI bar overlaid on the CRM using a browser extension, which looks embedded but is technically a separate application. ## The scenario where our choice wins Any customer whose agents spend their day in the CRM as their primary system of record. When the contact centre interface is a separate window or application, agents lose time to context-switching, miss screen pops when their CRM is on a different monitor or minimised, and must manually log call outcomes — because the two systems do not share a data layer, only a trigger event. Particularly valuable in service-heavy contact centres where agents need deep CRM data during the call (account history, open cases, product records) and where auto-creating cases or linking activities to conversations is a business requirement, not a nice-to-have. ## The one-sentence axiom claim > "ExpertFlow embeds contact centre controls natively inside the CRM using the > CRM's own extension framework — unlike standalone agent desktop or CTI-bar > overlays — which means agents operate in a single interface, context never > breaks on screen pop, and conversation data writes directly to CRM records > without manual logging." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | Salesforce and Dynamics connectors via packaged CTI adapter; standalone desktop exists | Integration depth beyond screen pop; auto case creation; single-interface operation | | Amazon Connect | Salesforce integration via AWS CRM Connector; separate Connect agent workspace | Same; also: no Dynamics native embedding | | Five9 | CRM integrations via CTI adapters; separate Five9 agent desktop default | Agent context-switching; manual activity logging overhead | | Cisco Finesse | Gadget-based extensions to Finesse desktop; separate from CRM | Finesse is the primary interface, not the CRM — inverse of ExpertFlow's model | | NICE CXone | CRM integrations via packaged connectors with screen pop; separate CXone desktop | Context-switching; integration depth limited by connector version | --- Canon Axiom: Open API Agent State vs. Proprietary CTI Middleware ID: axiom-006 Domain: cti-crm Claim: "ExpertFlow exposes agent state and media events through open REST and WebSocket" # Open API Agent State vs. Proprietary CTI Middleware ## The choice ExpertFlow made ExpertFlow exposes agent state — ready, busy, after-call work, wrap-up codes — and media events (call connected, call ended, chat message received) through open REST and WebSocket APIs with documented, stable contracts. Any authorised application can subscribe to these events or drive state transitions. There is no proprietary middleware, SDK installation, or vendor-specific CTI protocol required to build integrations on top of ExpertFlow's agent layer. ## The alternative (who made it and why it exists) Legacy CTI platforms — Cisco JTAPI, Avaya TSAPI, Genesys T-Server — expose agent and call state through proprietary middleware protocols. These protocols are powerful and mature but require vendor-specific SDKs, specialist expertise, and ongoing maintenance as platform versions change. An integration built on Cisco JTAPI is deeply coupled to the Cisco version it was developed against and requires re-certification on upgrade. Many first-generation CCaaS platforms moved from CTI middleware to REST APIs but publish only partial state surfaces — enough for packaged integrations but not enough for customers to build arbitrary automations on top of agent state. ## The scenario where our choice wins Enterprise customers whose CRM or business application teams want to build custom automations triggered by contact centre events — automatically update CRM fields when an agent changes to after-call work, trigger a workflow when a call ends with a specific wrap-up code, display contextual information in a custom business application when an agent connects to a call — without engaging ExpertFlow professional services or waiting for a connector update. Also: customers with bespoke CRM deployments (customised SAP, proprietary industry apps) where no packaged connector exists and the integration must be built from scratch. Open APIs mean any competent developer can build the integration using standard HTTP and WebSocket tooling. ## The one-sentence axiom claim > "ExpertFlow exposes agent state and media events through open REST and WebSocket > APIs — unlike proprietary CTI middleware that requires vendor-specific SDKs > and specialist integration expertise — which means any authorised application > can build contact-centre-triggered automations using standard tooling, without > dependency on ExpertFlow professional services or connector release cycles." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE | JTAPI / CTI OS SDK; proprietary; version-coupled | Integration build cost; upgrade risk; specialist dependency | | Avaya | TSAPI / DMCC; proprietary SDKs | Same as Cisco; particularly acute for custom CRM integrations | | Genesys Engage | T-Server CTI middleware; REST APIs available but partial surface | Partial state exposure; packaged connectors for standard CRMs only | | Five9 | REST APIs available; full state surface limited to packaged connector configurations | Custom automation capability; bespoke CRM depth | | Webex Contact Center | REST APIs available but contact-centre-operations focused; agent state events limited | Real-time agent state subscription for business application integration | --- Canon Axiom: LLM-Agnostic Bot Architecture ID: axiom-007 Domain: conversational-ai Claim: "ExpertFlow's dialog layer is decoupled from any specific LLM provider through" # LLM-Agnostic Bot Architecture ## The choice ExpertFlow made ExpertFlow's conversational AI layer is decoupled from any specific LLM provider. The dialog orchestration logic — conversation state, intent routing, handoff triggers, RAG retrieval — runs in a layer that communicates with LLMs through a configurable adapter. The underlying model (OpenAI GPT, Anthropic Claude, Google Gemini, a locally hosted open-source model) can be changed or swapped without modifying the dialog flow or the handoff integration. On-premise customers can run a locally deployed LLM; cloud customers can use whichever model best fits their requirements. ## The alternative (who made it and why it exists) Several CCaaS platforms with AI features have built their AI layer on a single LLM provider, tightly coupling the bot product to that provider's API. Others have built proprietary NLU engines that are the only supported model backend. This approach simplifies the vendor's engineering: one API contract to maintain, one model version to test against, one pricing model to pass through to customers. It is commercially rational for the vendor but creates strategic risk for the customer — they are locked into a specific AI vendor's pricing, capabilities, and data processing terms. ## The scenario where our choice wins Regulated industries (banking, healthcare, government) that cannot send customer conversation data to specific cloud providers (e.g., cannot use OpenAI due to US data processing concerns). These customers need a locally hosted LLM option that is structurally the same as the cloud option — the same dialog logic, the same handoff path, the same knowledge base integration. Also: customers in markets with rapidly evolving LLM options who want to benefit from improved models as they become available (e.g., switch from one model to a better-performing successor) without rebuilding their bot configuration or retraining intent classifiers. ## The one-sentence axiom claim > "ExpertFlow's dialog layer is decoupled from any specific LLM provider through > a configurable adapter — unlike platforms that embed a single AI vendor's model > as the required backend — which means customers can run an on-premise model for > data sovereignty or swap providers as the AI landscape evolves, without > reconfiguring the bot or the handoff path." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | AI features built on Google CCAI; LLM selection limited to Genesys AI or Google | Customers who cannot use Google CCAI for data residency; model flexibility | | Amazon Connect | Amazon Lex as the primary NLU; tight AWS ecosystem coupling | Non-AWS customers; data processing concerns around AWS AI services | | Salesforce Agentforce | Einstein / OpenAI backend; vendor-locked AI model | Data residency; customers with OpenAI contractual restrictions | | Webex AI | Cisco AI cloud; proprietary NLU fallback available | Non-Cisco AI cloud; regulated industries needing on-prem model execution | | NICE CXone | CXone AI backend; limited external LLM integration | Model flexibility; on-premise LLM option for regulated deployments | --- Canon Axiom: RAG-Grounded Bot Responses vs. Fine-Tuned Model Deployment ID: axiom-008 Domain: conversational-ai Claim: "ExpertFlow grounds bot responses by retrieving from the customer's live knowledge" # RAG-Grounded Bot Responses vs. Fine-Tuned Model Deployment ## The choice ExpertFlow made ExpertFlow's conversational AI generates answers by retrieving relevant content from the customer's own knowledge base at query time (Retrieval-Augmented Generation — RAG) and grounding the LLM's response in that content. The knowledge base is updated independently of the AI model: when a policy, product description, or procedure changes, the knowledge base is updated and the bot immediately reflects the change without any model retraining or redeployment. The model itself remains a general-purpose LLM; it is not fine-tuned on customer-specific content. ## The alternative (who made it and why it exists) Some AI bot platforms ground their responses by fine-tuning a model on the customer's content — feeding training examples derived from the customer's knowledge base into a model training run to produce a customer-specific model version. This approach was popular before RAG architectures matured because it was the primary technique for making an LLM "know" domain-specific information. Fine-tuning produces a model that answers from baked-in knowledge rather than retrieved context. Fine-tuning has genuine uses (teaching a model a specific response style or output format) but it is a poor knowledge-management strategy: retraining takes hours to days, introduces cost, and requires an MLOps pipeline to manage model versions. When information changes, the model is stale until the next training run. ## The scenario where our choice wins Any customer whose knowledge base changes more frequently than a quarterly retraining cycle — which is essentially every customer. Product pricing, compliance policies, escalation procedures, support articles: these change continuously. In a fine-tuned model, every change requires a training run. In an RAG architecture, the change propagates immediately on knowledge base update. Critically important in regulated industries: if a compliance policy changes and the bot continues to answer from a stale fine-tuned model for three weeks while a retraining job is queued, the organisation has a compliance liability. RAG eliminates this gap. ## The one-sentence axiom claim > "ExpertFlow grounds bot responses by retrieving from the customer's live knowledge > base at query time via RAG — unlike fine-tuned models that bake knowledge into > model weights — which means policy and product changes propagate immediately > without retraining, and there is no stale-model liability for regulated content." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | IBM watsonx Assistant | Training-based NLU; RAG available as add-on but not the default architecture | Real-time knowledge propagation; retraining cycle overhead for content changes | | Nuance (now Microsoft) | Fine-tuned industry models; domain-specific model packages | Content freshness; compliance-critical customers with frequent policy updates | | Google CCAI | Generative AI with fine-tuning option; RAG available via Vertex AI | Operational simplicity; no MLOps pipeline required for knowledge updates | | Kore.ai | Training-based NLU with RAG option | Same freshness argument; regulated-industry liability for stale knowledge | --- Canon Axiom: Single Conversation Object Spanning All Channels ID: axiom-009 Domain: core-objects Claim: "ExpertFlow models every customer interaction as a single Conversation spanning" # Single Conversation Object Spanning All Channels ## The choice ExpertFlow made Every customer interaction in ExpertFlow — regardless of channel (voice, chat, email, social) — is represented as a single Conversation object with a persistent identifier. A conversation may contain multiple sessions across channels: a chat bot session followed by a voice call followed by an agent chat session are all sessions within the same conversation. The conversation carries participant identity, the full activity log, AI summaries, recordings, and the CRM record link. An agent who receives a transferred or re-contacted customer sees the entire prior interaction history across all channels in one view. ## The alternative (who made it and why it exists) Traditional contact centre platforms grew from single-channel roots — voice ACDs that were extended to handle email, then chat, then social through separate modules or acquisitions. Each channel has its own session record, stored in its own table or service. A phone call creates a call record; a chat creates a chat transcript; an email creates a ticket. These records are linked to the customer's CRM record eventually, but through separate sync processes and with varying data fidelity. When a customer calls about a chat they had yesterday, the voice agent must open a separate chat history view — if it exists — and manually piece together the prior context. There is no native concept of a cross-channel "conversation" that carries both interactions. ## The scenario where our choice wins Omnichannel customer journeys where customers engage across channels over a single issue or resolution path. Common in financial services (customer starts a chat about a dispute, calls back the next day) and healthcare (appointment booked by chat, confirmed by voice). When the conversation object is unified, the second agent immediately sees the prior channel context without asking the customer to repeat themselves — which drives measurable CSAT improvement and reduces average handle time on subsequent contacts. Also: AI handoff scenarios where a bot conversation must transfer to a human with full context — the unified conversation object is the natural carrier for the bot transcript, intent, and sentiment score that the human agent receives. ## The one-sentence axiom claim > "ExpertFlow models every customer interaction as a single Conversation spanning > all channels and all sessions — unlike per-channel session records that require > manual cross-referencing — which means agents on any channel always see the > complete prior context, customers are never asked to repeat themselves, and > AI-to-human handoffs carry full bot context natively." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | Unified history available but cross-channel conversation object is newer feature; legacy channels per-session | Omnichannel journey continuity; AI handoff context | | Cisco CCE | Voice-native; digital channels via separate Cisco Digital (formerly IME) with separate records | Cross-channel context assembly; Cisco customers with digital + voice | | Salesforce Service Cloud | Omni-Channel routes interactions; case is the linking object but not a real-time conversation carrier | Real-time handoff context; bot-to-human with conversation state | | Five9 | Interaction records per channel; customer journey view requires BI/reporting layer | In-session cross-channel context for agents | | Freshdesk Contact Center | Ticket-based model; voice and chat linked to tickets retroactively | Real-time, in-call context across prior channels | --- Canon Axiom: Open Standards SSO via Keycloak and OAuth2 ID: axiom-010 Domain: security Claim: "ExpertFlow authenticates all users through open-standards OAuth2 / OIDC via" # Open Standards SSO via Keycloak and OAuth2 ## The choice ExpertFlow made ExpertFlow handles authentication and identity through open standards: OAuth2, OpenID Connect, and SAML2. The identity layer is implemented using Keycloak, an open-source identity and access management platform, which can federate with any standards-compliant identity provider — Active Directory, LDAP, Azure AD, Google Workspace, Okta, or any SAML2 IdP. Agents, supervisors, and administrators authenticate once through the organisation's existing identity provider; there is no separate ExpertFlow identity store to provision or maintain. The API gateway (KongHQ) enforces token-based authorisation on all platform APIs using standard OAuth2 tokens. ## The alternative (who made it and why it exists) Several enterprise contact centre platforms — particularly those that grew from on-premise roots — maintain proprietary user directories and authentication mechanisms. Integration with corporate Active Directory requires a proprietary synchronisation agent or a vendor-supplied LDAP connector with its own configuration schema and version dependencies. SSO is available as a premium feature, often requiring a specific licence tier, and is integrated through vendor-specific SAML implementations that may not support all IdP configurations. This design predates modern identity standards and persists because migrating a large installed base to OAuth2/OIDC requires significant re-engineering of session management, token handling, and permission models. ## The scenario where our choice wins Enterprise IT security teams that have standardised on a corporate IdP (Azure AD, Okta, or on-premise AD with AD FS) and require all business applications to authenticate through it. These teams will not provision a separate identity store for contact centre agents and will not accept a proprietary LDAP sync agent running on their infrastructure. Also: organisations with strict privileged access management requirements where all service-to-service API calls must use short-lived OAuth2 tokens with defined scopes — not API keys or basic auth credentials. Open-standards token handling is auditable, rotatable, and integrable with enterprise IAM tooling. ## The one-sentence axiom claim > "ExpertFlow authenticates all users through open-standards OAuth2 / OIDC via > Keycloak, federating with any corporate IdP — unlike platforms with proprietary > identity stores or vendor-specific SAML implementations — which means no > separate agent directory to provision, no proprietary sync agents to maintain, > and full compatibility with enterprise IAM governance requirements." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE | Cisco Unified Intelligence Center for auth; LDAP sync via Cisco LDAP Integration; proprietary user DB | Separate agent provisioning; LDAP sync agent maintenance; limited OIDC | | Avaya | Proprietary user management; LDAP integration available but connector-based | Provisioning overhead; SSO premium tier; limited IdP flexibility | | Genesys Cloud | OAuth2 / OIDC SSO available; identity provider federation strong | Competitive parity on cloud; edge is on-premise Keycloak for regulated deployments | | Five9 | SAML SSO available; Okta and Azure AD supported for cloud | On-premise IdP federation; API gateway OAuth2 scope enforcement | | Mitel | Proprietary user management on-premise; SSO via add-on module | Setup complexity; no standard OAuth2 token model for API access | --- Canon Axiom: On-Premise Data Residency as a First-Class Deployment Option ID: axiom-011 Domain: security Claim: "ExpertFlow's on-premise deployment runs the same code and delivers the same" # On-Premise Data Residency as a First-Class Deployment Option ## The choice ExpertFlow made ExpertFlow's on-premise deployment is architecturally identical to its cloud deployment — the same codebase, the same feature set, the same operational model. On-premise is not a legacy product tier or a separately maintained code branch; it is one of the supported deployment topologies. Customers deploying on-premise get the same capabilities as cloud customers, managed through the same Helm charts and GitOps tooling. No capability is withheld from on-premise deployments on the grounds that it requires vendor-operated infrastructure. ## The alternative (who made it and why it exists) Most cloud-first CCaaS vendors have eliminated or are eliminating on-premise options. Those that offer on-premise do so through separate product lines — typically legacy VM-based installers that run significantly behind the cloud product in feature parity. The on-premise product does not receive AI features, new digital channels, or modern integration APIs at the same cadence as the cloud product, because maintaining two codebases (cloud and on-premise) with equal feature parity is operationally expensive for the vendor. This creates a structural disadvantage for regulated-industry customers who are on the on-premise tier: they are perpetually behind on features, and the vendor's sales motion increasingly pushes toward cloud migration. ## The scenario where our choice wins Central banks, government ministries, defence contractors, and healthcare systems operating under data sovereignty regulations that prohibit customer data (voice recordings, conversation transcripts, client identity records) from leaving jurisdiction-controlled infrastructure. For these organisations, cloud-hosted CCaaS is not an option regardless of price or feature advantages. They need a modern contact centre platform that runs entirely within their perimeter. The ExpertFlow differentiator in this scenario is that on-premise deployment does not mean accepting a stripped-down product. AI features (RAG bots, AI assist), CRM embedding, omnichannel routing — all run on-premise identically to cloud. ## The one-sentence axiom claim > "ExpertFlow's on-premise deployment runs the same code and delivers the same > features as the cloud deployment — unlike CCaaS vendors where on-premise is a > legacy tier with a lagging feature set — which means regulated-industry customers > who cannot use cloud can still access AI, omnichannel, and modern integrations > without compromise." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | Cloud-only; Genesys Engage is the on-premise product (separate, behind in features) | Feature parity; AI capabilities on-premise; single vendor, one platform | | Amazon Connect | AWS-only; no on-premise deployment | Any customer with on-premise requirement | | Webex Contact Center | Cloud-primary; on-premise CCX/CCE is the legacy path, not the roadmap | Feature parity; Cisco's strategic direction is cloud, not on-premise | | Twilio Flex | Cloud-only | Any customer with on-premise requirement | | Five9 | Cloud-only | Any customer with on-premise requirement | --- Canon Axiom: Kubernetes-Native Deployment ID: axiom-012 Domain: deployment Claim: "ExpertFlow is deployed entirely as Kubernetes workloads via Helm charts —" # Kubernetes-Native Deployment ## The choice ExpertFlow made ExpertFlow is built as a collection of containerised microservices deployed on Kubernetes. Every component — routing engine, media server, conversation store, AI layer, CRM adapters, identity layer — runs as a Kubernetes workload. Deployment is defined entirely through Kubernetes manifests and Helm charts. There are no VMs to provision, no installer scripts to run, and no platform-specific agent software to deploy on host operating systems. The operational model is identical whether the target environment is an on-premise bare-metal cluster, a private VMware cluster, Amazon EKS, or Azure AKS. ## The alternative (who made it and why it exists) Traditional on-premise contact centre platforms — Cisco CCE, Genesys Engage, Avaya Aura — were designed for VM-based deployment. Installation involves running wizard-driven installers on Windows Server VMs, configuring platform-specific services, and maintaining a specific hardware and OS certification matrix. Upgrades follow complex migration procedures documented in extensive runbooks. First-generation cloud deployments of these platforms lifted the same VM-based architecture to cloud VMs, adding cloud hosting without changing the operational model. Some newer platforms moved to containers but retain monolithic architectures or proprietary orchestration layers rather than standard Kubernetes. ## The scenario where our choice wins Organisations that have adopted Kubernetes as their standard application deployment platform (increasingly the default for enterprises with cloud or private cloud infrastructure) and want to manage their contact centre platform using the same GitOps toolchain, monitoring stack (Prometheus/Grafana), and infrastructure-as-code practices as the rest of their application estate. Operations teams that have eliminated VM administration skills and do not want to hire them back to run a contact centre platform. Kubernetes-native also enables cost efficiency through workload density: ExpertFlow shares cluster resources with other workloads during off-peak hours rather than requiring dedicated VMs at peak capacity 24/7. ## The one-sentence axiom claim > "ExpertFlow is deployed entirely as Kubernetes workloads via Helm charts — > unlike VM-based or proprietary-orchestration platforms — which means it is > managed through standard GitOps tooling, shares cluster resources with other > workloads, and behaves identically across on-premise, AWS, and Azure environments > without separate operational runbooks." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco CCE | VM-based Windows Server deployment; proprietary installer; separate upgrade procedures per component | Organisations with Kubernetes-standard operations; no VM admin overhead | | Genesys Engage | VM-based deployment (Linux/Windows); container option emerging but not default | Same; Kubernetes-first organisations; operational consistency | | Avaya Aura | VM-based; proprietary platform software and upgrade procedures | No overlap with modern Kubernetes operations teams | | Genesys Cloud | SaaS; customer has no deployment model choice | On-premise and private cloud requirements; infrastructure control | | Amazon Connect | AWS-managed SaaS; no customer deployment | Same as above | --- Canon Axiom: Cisco CCE Co-existence Model ID: axiom-013 Domain: deployment Claim: "ExpertFlow runs alongside Cisco CCE/CCX during migration — unlike replace-and-" # Cisco CCE Co-existence Model ## The choice ExpertFlow made ExpertFlow can operate alongside existing Cisco Unified Contact Center Enterprise or Contact Center Express deployments — not as a replacement that requires decommissioning Cisco infrastructure before go-live, but as a co-resident platform that takes over specific functions (agent desktop, digital channels, routing logic) while Cisco handles others (PSTN connectivity, SIP, CUCM voice infrastructure). Migration proceeds in phases: agent groups, channels, or sites move to ExpertFlow independently while the remaining Cisco components continue operating. There is no mandatory cutover weekend. ## The alternative (who made it and why it exists) The default model in Cisco's own CCaaS roadmap is migration to Webex Contact Center — a cloud-hosted platform that replaces CCE/CCX end-to-end. Cisco's migration guides and professional services are designed around a cutover model: plan the migration, replicate configuration, run parallel for a test period, then execute a cutover. This is rational for Cisco because Webex Contact Center is an SaaS product that cannot co-exist with CCE on a per-feature basis; it requires full ownership of call handling. Third-party migration tools exist (from partners like Black Box, Avtex) but these still work on a per-site cutover model and are designed to migrate away from Cisco, not to operate alongside it during an extended transition. ## The scenario where our choice wins Large Cisco CCE customers (200+ agents) that have invested significantly in Cisco infrastructure — CUCM, PSTN gateways, dedicated Cisco voice hardware — and cannot write off that investment in a single migration event. These customers want to modernise the agent experience and add digital channels immediately, while retiring Cisco components on a multi-year depreciation schedule. Also: customers with regulatory constraints that prevent cutover-style migrations (financial services with change freeze periods, healthcare with 24/7 uptime SLAs that cannot accept a migration risk window). ## The one-sentence axiom claim > "ExpertFlow runs alongside Cisco CCE/CCX during migration — unlike replace-and- > cutover tools that require decommissioning Cisco infrastructure before go-live > — which means customers access modern capabilities immediately while retiring > Cisco components at a pace determined by their budget and risk tolerance, not > by a migration vendor's cutover model." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Cisco Webex Contact Center | Cisco's own migration path; cloud-only; requires CUCM-to-cloud voice migration | Customers retaining CUCM; multi-year retirement plan; regulated migration requirements | | Genesys Cloud | Migration tooling for CCE; requires cutover; geographically cloud-POP dependent | Customers who cannot do cloud SIP routing; phased migration without cutover | | NICE CXone | Replace-and-migrate model; no Cisco co-existence | Same as above | | Five9 | Replace-and-migrate; no native Cisco co-existence architecture | Same; particularly for customers with CUCM investments they intend to retain | --- Canon Axiom: Unified Client Identity Spanning All Channels ID: axiom-014 Domain: core-objects Claim: "ExpertFlow resolves every inbound contact to a single client identity record" # Unified Client Identity Spanning All Channels ## The choice ExpertFlow made ExpertFlow maintains a single client identity record that spans all channels. A customer who contacts via phone, chat, email, or social is recognised as the same person regardless of the channel through which they arrive. Identity is resolved at contact arrival — by phone number, email address, social handle, or a customer ID passed from the CRM — and linked to the ExpertFlow client record. All conversations, regardless of channel, are attributed to that unified identity. Supervisors and agents see a single interaction history view, not a per-channel view. ## The alternative (who made it and why it exists) Legacy contact centre platforms that grew channel by channel create per-channel identity representations: a caller record in the ACD, a chat user record in the chat platform, an email contact in the email system. These are linked to the CRM contact record after the fact, through synchronisation jobs or screen-pop lookups that happen per contact, per channel. The identity records are not unified in the contact centre platform itself — only in the CRM. The implication is that without opening the CRM, an agent or supervisor cannot see across channels for a single customer. And in the contact centre platform's own reporting, the same customer who called and then chatted appears as two separate contacts. ## The scenario where our choice wins Outbound campaign management: when a supervisor loads a campaign against a client list, ExpertFlow resolves the identities from the list against the unified client record and can suppress contacts who have a recent inbound interaction still open — preventing the embarrassing scenario of calling a customer with an active complaint. Per-channel identity records cannot support this suppression without a complex cross-system join. Also: financial services and healthcare, where recognising a returning customer across channels is a regulatory expectation (KYC) and a service quality requirement. An agent who sees the customer's full cross-channel interaction history can skip re-identification questions and focus on resolution. ## The one-sentence axiom claim > "ExpertFlow resolves every inbound contact to a single client identity record > spanning all channels — unlike per-channel identity stores that link to the > CRM only after contact — which means agents always have cross-channel history > at contact arrival, and outbound campaigns can suppress based on any recent > channel interaction." --- - [x] The architectural choice is named (a decision, not a value or feature) - [x] A competitor or industry default that made the other choice can be named - [x] A specific customer scenario where our choice wins is named - [x] The one-sentence claim is complete and readable - [x] This axiom remains true if the underlying implementation technology changes --- ## Competitors for the relevant solution pattern(s) | Competitor | Their approach | Where our axiom creates an edge | |---|---|---| | Genesys Cloud | Customer record spans channels; journey management available | Good competition — ExpertFlow edge is on-premise identity handling and open API | | Cisco CCE | Per-channel customer records (call, chat, email separate); unified via CRM only | Cross-channel context before CRM screen pop loads; outbound suppression | | Five9 | Contact records per channel; CRM is the identity master | Same; particularly for outbound suppression and agent-side cross-channel view | | Salesforce Service Cloud Omni-Channel | Case is the linking object; customer identity unified in Salesforce | In-contact-centre-platform identity (without opening CRM); campaign suppression | ---