Services

Last updated 02/06/2025

1. Contact 

A Contact is the fundamental, singular record representing an individual and stands as the principal identity within your environment. There are no mandatory fields at the contact level, but we suggest including data fields needed to differentiate one contact from another (for instance, “First Name,” “Last Name,” “Email,” “Phone”). If an incoming user’s communication channel matches an existing contact, the system automatically merges them, preventing duplicate records. When used in a GDPR context, only fields necessary for processing are captured, with the option for full or partial erasure or rectification requests; this approach supports anonymising personal identifiers while preserving lead-level transaction data in anonymised form.

2. Contact Communication Channels

Contact Communication Channels encompass all the ways users can initiate or continue a conversation with the AI solution, including the embedded website Widget (a JavaScript snippet that appears as a chat button or interface), WhatsApp (using a business account on Meta’s platform for inbound and outbound conversations), and a Test channel (an internal environment where the Zeus team simulates user interactions). Each channel has its own usage guidelines, such as WhatsApp’s requirement for template approvals if the brand sends outbound notifications, and may include optional customisation like disclaimers or triggers on the Widget.

3. Lead

A Lead is a subordinate record tied to a single Contact, used to track a user’s inquiry, application, or interest. It is considered an “intent record” that forms the basis of any commercial or support relationship. A single Contact can have multiple Leads, each capturing unique data pertinent to that specific inquiry (e.g. “Loan Purpose,” “Deposit Amount”). Any needed optional or domain-specific fields can be defined on the lead level. If two leads share the same communication channel ID, the system merges them and associates them with the same underlying contact. Leads typically move through a lifecycle (e.g. “In Progress” to “Successful”) and serve as a reference point for compliance, marketing analytics, and user intent.

4. Attribute (Data Field)

An Attribute or Data Field is an individually defined piece of information the system captures or references during user interactions. Each field is associated either with a Contact (representing an individual’s identity) or a Lead (representing a specific inquiry or opportunity), and is assigned a system-generated unique identifier (UUID) to ensure there are no collisions or ambiguities. Labels such as “Deposit,” “Email,” or “Property Value” clarify a field’s purpose, and the type can be string, enum, integer, decimal, boolean, or other relevant formats. During interactions, the AI fills these fields with user-provided data (e.g. “I have a 250,000 deposit” populates the “Deposit” field with 250,000). Attributes also guide the AI in prompting users (e.g. “What is your deposit amount?”) and can include validation rules or constraints. They must comply with data governance policies and remain correctly scoped: identity-level data goes on the Contact, while inquiry-specific data goes on the Lead. A version history is maintained if a field’s definition is altered over time.

5. SuperAgent

A Super Agent is a specialised instance of an AI agent with a specific role or function, also called “Superhuman”. A single Zeus account can have multiple Super Agents, each possibly labelled according to its purpose (e.g. “Appointment Booking Super Agent,” “Sales Pre-Qualification Super Agent,” or “Nurture Super Agent”). Effectively, it is a distinct conversation flow plus brand persona, dedicated to handling user data relevant to its role. This name shift clarifies that it is an AI-based function rather than a live human staffer, ensuring users understand they are interacting with an automated agent.

6. Super Agent Communication Channel

A Super Agent Communication Channel defines the specific pathway by which a particular Super Agent interacts with end-users. While a Contact’s Communication Channel indicates how a user reaches the system, a Super Agent Communication Channel identifies how the AI agent itself engages with users, allowing for multi-channel deployments under the same account. The main types include WhatsApp (requiring a linked WhatsApp number ID and phone number), Widget (an embedded interface in the client’s site where the Super Agent handles live chat), and Test (a non-customer-facing environment for quality assurance or flow development). This separation allows a single Super Agent to operate across multiple channels without interfering with others.

7. Conversation Flows

Conversation Flows are structured interaction paths the AI follows when engaging with users. They may be visualised as flowcharts or decision trees, containing prompts, branching logic, and data capture nodes. They can adapt to user input, incorporate disclaimers for compliance, capture lead scoring details, and track version control so updates to an existing flow don’t conflict with earlier data. In regulated industries, disclaimers can appear at critical points (e.g. “By continuing, you confirm you understand X regulation”), and each flow typically includes prompts, fallback messages, success or exit steps, and conditions dictating the path a conversation can take.

1. Flow Node

  • A Flow Node is a functional step in a conversation flow, instructing the Superagent (Superhuman) on what to do next. It can request user data (e.g. “Please provide your phone number”), make route decisions based on user inputs or existing data fields (e.g. “If mortgage type = Buying, ask about deposit”), or embed compliance disclaimers (e.g. “By providing details, you consent to our Privacy Policy”). Each node may map user input to a specific Attribute, and any transitions between nodes are logged for audit trails, especially where legal acceptance or disclaimers are involved. Some flow nodes are default, such as those prompting a user’s name or offering an appointment, while specialised nodes may require custom development.

2. Flow Edge

  • A Flow Edge defines the directional link between two Flow Nodes, dictating the conversation path. When a node finishes executing, the system checks conditional edges in order and follows the first whose condition matches. If no condition is satisfied, the default edge is used. Each node has at least one input edge (except the Intro node) and typically only one unconditional output edge. By structuring these edges carefully, the conversation avoids dead ends and can branch in multiple ways depending on user responses or attributes in the system.

8. Chat Conversation

A Chat Conversation is a temporal session of messages exchanged between a user (tied to a Contact and possibly a Lead) and the AI. The user can send unlimited messages, and the AI responds accordingly, all within the same conversation context if it remains the same contact and lead. This allows for clarifications and multiple rounds of interaction without creating separate sessions. A conversation ends or restarts when the communication channel session changes or a new contact/lead is triggered. This structure reduces duplication by consolidating the ongoing discussion under one record.

9. Sales Flow

A Sales Flow is a specialised conversation route that rapidly assesses a user’s suitability as a lead, gathering core pre-qualification information such as deposit amount, property type, or objectives. It may apply lead scoring to determine if the user meets an “ideal customer” profile. Where relevant, disclaimers (e.g. for regulated financial products) are included. If thresholds are met, the flow prompts the user to schedule a call, collect extra details, or enter a CRM pipeline, ensuring consistent lead capture and compliance with any necessary disclosures.

10. Support Flow

A Support Flow handles user complaints or support requests by steering them through diagnostic questions, referencing internal FAQs or knowledge snippets, and often capturing order or reference numbers. It can update or create tickets in a helpdesk system if deeper follow-up is needed. Disclaimers can clarify that the information provided is general support guidance. When no immediate resolution is found, the flow may escalate to a phone support queue or a specialist team. This ensures a systematic record of user concerns is kept for further action.

11. Nurture Flow

A Nurture Flow is a gentler script for users who are not ready to convert or speak with sales. It captures simpler data—like email or approximate needs—and offers further resources (e.g. newsletters, product demos) without pushing for an immediate appointment. If a user’s responses unexpectedly show high interest, it can redirect them to a more direct sales path. By collecting minimal but strategic information, the Nurture Flow respects a user’s hesitation while enabling future re-engagement or lead scoring.

12. LLM Usage

LLM Usage refers to any interaction where the Large Language Model (LLM) is invoked to process, generate, or respond to user messages. It is charged at £8.90 per 100 chat conversations, each conversation allowing unlimited inbound and outbound messages with the AI. The system tracks the number of separate conversation sessions and levies fees once 100 conversations are reached. Usage logs can be retained for transparent cost checks, and this billing metric applies to all standard channels (like website widgets or integrated API calls).

13. WhatsApp Usage

WhatsApp Usage is a distinct charge from LLM usage, set at £4.50 per 100 conversations carried out on the WhatsApp channel, where a conversation lasts for 24 hours with unlimited messages between the same user and the AI. After 24 hours, a new conversation is counted if the user returns. The fee covers not only the AI’s generation of messages but also the underlying WhatsApp Business infrastructure. Tracking is done per phone-based session, and any outbound messaging templates must comply with Meta’s policies. These costs appear in regular billing cycles, separate from general LLM usage.

14. Tools

Tools are discrete components or modules the main system (Zeus AI) can call upon to perform specialised tasks that go beyond straightforward text exchange. In a large language model environment, a Tool might be an external function or subsystem—like a calculator, knowledge database, or code generator—that the AI can invoke via well-defined function names, inputs, and outputs. This architecture offloads certain tasks from the conversation model and allows each Tool to maintain its own code, rules, or data. Tools handling sensitive information must meet security standards, and the system gracefully handles errors if a Tool fails. Because Tools can change, there is no liability for downtime or updates in a third-party Tool that disrupts the flow.

15. Widgets

A Widget is a user-facing JavaScript component placed on a client’s website to enable live chat functionality with the AI. It usually appears as a pop-up or embedded interface and can be customised with brand colours, legal disclaimers (e.g. links to privacy policies), and triggers such as timed pop-ups or notification sounds. The widget’s snippet is pasted into the site’s HTML, calling a remote script to set up the chat UI. It may store session data locally, preserving conversation context across a user’s visit. Advanced branding (“custom skins”) could require extra design work, and any local storage or tracking must adhere to relevant privacy laws.

16. API Keys and “API”

An API (Application Programming Interface) is a set of RESTful endpoints through which external systems exchange data with the platform. API Keys are unique credentials required to authenticate these calls, and must be kept secure to avoid malicious access. Clients must follow the official API Guide, which details permissible endpoints, request/response schemas, and example code. All traffic should occur over HTTPS, with optional rate limits to prevent excessive calls. New API versions may be introduced, and clients should track deprecation notices to maintain compatibility. Liability for misuse of keys typically falls to the client.

17. Webhooks

Webhooks are outbound callbacks triggered by events in the system and sent via HTTP POST to a client-defined URL. Instead of the client polling for updates, Webhooks proactively push JSON or similarly structured payloads for events like lead creation or message reception. If a webhook delivery fails (timeout or non-2xx status), the system retries at intervals (15 minutes, 30 minutes, 1 hour, etc.). Repeated failures can disable a webhook until remedied. It is the client’s responsibility to ensure their receiving endpoint is secure and compliant, especially when personal data is included in the payload.

18. Custom Development

Custom Development refers to work exceeding standard, out-of-the-box functionalities or features. Typical examples include integrating with niche CRMs, implementing sophisticated compliance logic, or adding unique role-based permission structures. This process usually starts with a scoping call to outline requirements, followed by a quote for labour time or a day rate. Thorough QA is essential to prevent conflicts with core features; once tested, changes are rolled into the live environment. Clients often sign disclaimers acknowledging that additional bug fixes or expansions beyond the agreed scope require new approval or extended development hours.

19. Support

Support ranges from Basic, Premium, to Dedicated Account Manager tiers, ensuring clients have the help they need once the platform is live. Basic support typically relies on email or ticket submissions with a ~48-hour response window. Premium includes phone or video calls, aiming for ~4-hour responses on urgent issues, and can involve screen-sharing or detailed walkthroughs. The Dedicated Account Manager option provides proactive oversight of performance metrics, monthly or fortnightly check-ins, and faster escalation paths to developers or compliance experts, particularly beneficial for high-volume or business-critical setups.

20. Knowledge Base / Knowledge Database / Knowledge Snippets

A Knowledge Base or Knowledge Database is a repository of short factual snippets about a client’s brand, product details, addresses, or policies. Each snippet is designed to be concise (typically 3–5 sentences) and focused on a single fact, making it easy for the AI to retrieve the exact information needed. Clients curate these snippets and are responsible for their accuracy, updating them when facts or offers change. The conversation flow or AI can then call a function to search these snippets by keyword or topic, ensuring precise, brand-specific answers rather than relying on broad training data. Tiers may limit how many snippets can be stored, and regulated content (like financial or medical information) requires the snippet text to meet legal standards.

21. Lead Filters

Lead Filters are rules or queries that segment, route, or display leads based on chosen criteria. Users can define conditions like “Status equals New AND Source equals Website Chat” to group or highlight particular leads. Complex logic can also filter by custom fields (e.g. “Deposit is not empty” or “loanAmount > X”). This helps organise leads, trigger email notifications, or assign them to relevant teams. A filter builder interface typically offers various operators such as equals, not equals, starts with, is empty, or not empty.

22. Email Notifications

Email Notifications are automated alerts sent to designated recipients upon predefined triggers, such as new lead creation, a lead reaching “Successful” status, or a user requesting a callback. These notifications usually contain essential contact or lead information, any disclaimers for sensitive data, and a direct link to the record in the dashboard. Administrators can configure which events generate an email. If the mail server experiences delivery issues or bounce-backs, the system logs these errors but continues the main conversation flow unaffected.

23. Meta (WhatsApp) Management

Meta (WhatsApp) Management describes the process of integrating Zeus AI with the WhatsApp Business Platform under Meta. This requires business verification, linking a phone number ID, and abiding by Meta’s template-approval policies when sending outbound notifications (e.g. appointment reminders). The AI relies on an API token to send and receive messages, with webhooks established so inbound messages from that phone number reach the correct AI endpoint. Clients must keep their brand identity and documentation up to date with Meta, especially if phone numbers or corporate details change, and remain compliant with ongoing policy updates from Meta.

24. Dashboard

A Dashboard is a secure, password-protected interface where clients can track performance metrics such as unique visitors, leads, qualified leads, and conversation drop-off points. It typically has pages for Analytics (showing trends and ratios), Leads (a table of all leads with CSV export options), and Flows (summaries of each conversation script, including version history). Users authenticate with unique credentials, and the system can log activity for auditing. Advanced compliance needs might include IP whitelisting or multi-factor authentication. This central location helps users monitor, manage, and refine how the AI interacts with leads in real time.

25. Integrations

An Integration is any mechanism that connects our SaaS platform with external systems, whether a CRM, payment gateway, or another third-party API. It typically involves shared credentials, REST endpoints, secure data exchanges, and mapping of data fields so that records flow seamlessly between platforms. Integrations may be simple, leveraging existing built-in connectors, or complex, requiring custom code. Clients bear responsibility for valid licences of the third-party software and for verifying data handling compliance. Maintenance may be needed if external APIs change, and any custom integration work is usually governed by the Custom Development clause.