Home Conversational Operations

Conversational Operations

By Admin General
• 20 articles

Agent Capacity

Support Portal includes an agent capacity system that governs how many conversations can be actively assigned to each agent at any given time. By enforcing per-agent limits, the platform prevents workload imbalance and ensures that response quality remains consistent — even during traffic spikes common in telecom contact centers and government service desks. Operational objective Agent capacity management addresses a core operational challenge: as conversation volume scales, unrestricted auto-assignment can overwhelm individual agents, leading to slower response times and diminished service quality. Capacity limits provide three key benefits: - Workload protection — Each agent receives only as many conversations as they can handle effectively, reducing burnout and missed messages. - Predictable assignment behavior — The auto-assignment engine respects capacity thresholds before routing new conversations, making staffing and forecasting more reliable. - Channel-appropriate pacing — Different communication channels demand different levels of attention. Capacity can be tuned per inbox so that live chat agents carry fewer simultaneous conversations than those handling email or asynchronous messaging. How capacity is determined A conversation counts toward an agent's capacity when it is assigned to that agent and is not yet resolved. The following states consume capacity: | State | Counts toward capacity | |---|---| | Open — actively being handled | Yes | | Pending — awaiting customer response | Yes | | Snoozed — temporarily paused | Yes | | Resolved — closed | No | This means that resolving conversations frees capacity immediately, while snoozing a conversation does not. Agents who need temporary relief should resolve or reassign conversations rather than snoozing them. Configuring capacity limits Capacity limits are configured at the inbox level. Each inbox can define a maximum number of concurrent conversations per agent, allowing you to tailor limits by channel type. Setting a capacity limit Navigate to Settings > Inboxes and select the inbox you want to configure. Open the Collaborators tab and locate the Auto Assignment section — enable it if not already active. Set the Max auto-assignment limit for the inbox, which defines the maximum number of open conversations that auto-assignment will route to a single agent through this inbox. Select Update to save the configuration. The limit applies to all agents assigned to that inbox. When an agent's assigned conversation count reaches the threshold, the auto-assignment engine skips that agent until their count drops below the limit. Recommended capacity values by channel Different channels require different handling speeds. The following values serve as starting points — adjust based on your team's experience and SLA targets. | Channel type | Suggested capacity | Rationale | |---|---|---| | Live chat / widget | 2–4 conversations | Real-time interaction requires focused attention. | | Email | 10–20 conversations | Asynchronous nature allows higher concurrency. | | Social messaging | 4–8 conversations | Response time expectations fall between chat and email. | | API / programmatic | Varies | Depends on the complexity of API-originated interactions. | Interaction with round-robin assignment Agent capacity works in conjunction with the round-robin auto-assignment engine. When a new conversation arrives in an inbox with auto-assignment enabled, the system follows this sequence: 1. Identify eligible agents — All agents assigned to the inbox who are currently online (or meet availability criteria) are considered. 2. Filter by capacity — Any agent whose current conversation count meets or exceeds the inbox capacity limit is excluded from the round. 3. Assign in rotation — Among the remaining eligible agents, the conversation is assigned to the next agent in the round-robin sequence. 4. Queue if no agent is available — If all eligible agents have reached their capacity limit, the conversation is placed in the Unassigned queue. It remains there until an agent's capacity frees up or a supervisor manually assigns it. This behavior ensures that conversations are never force-assigned beyond an agent's configured limit. Enterprise deployment patterns High-volume telecom support centers Telecom operators often handle thousands of concurrent conversations across multiple service tiers. A common configuration approach: - Tier 1 (general inquiries) — Set capacity to 6–8 per agent on the live chat inbox. These interactions are typically short and can be resolved quickly with canned responses. - Tier 2 (technical support) — Reduce capacity to 2–3 per agent. Technical troubleshooting requires deeper focus and longer conversation durations. - Tier 3 (escalation / regulatory) — Set capacity to 1–2. These are complex cases that may involve compliance review or cross-departmental coordination. By configuring separate inboxes for each tier, each with its own capacity value, the platform matches workload intensity to agent specialization. Tiered capacity by expertise Organizations with agents of varying experience levels can use capacity limits strategically: - Assign newer agents to inboxes with lower capacity limits, giving them time to handle each conversation thoroughly. - Senior agents handling routine interactions can operate with higher limits, maximizing throughput. - Specialized agents dealing with regulated processes (e.g., identity verification, contract disputes) should have lower limits to ensure compliance-quality responses. This approach pairs well with team-based routing. See Teams for details on structuring agent groups. Monitoring and managing capacity When all agents in an inbox reach their capacity, conversations accumulate in the Unassigned queue. Supervisors should monitor this queue to prevent response delays. Operational indicators to watch: - Growing unassigned queue — May indicate that capacity limits are too low relative to conversation volume, or that additional agents are needed during peak hours. - Agents consistently below capacity — May suggest limits are set too high, or that conversation volume does not justify the current staffing level. - Uneven distribution — If some agents consistently reach capacity while others do not, review agent availability settings and inbox assignments. Capacity data can be correlated with agent performance reports to refine limits over time. See Reports for available metrics. Relationship to other assignment features Agent capacity is one component of the broader assignment logic in Support Portal. Related capabilities include: - Auto-assignment — The underlying engine that distributes conversations. Capacity limits act as a constraint on this engine. See Auto Assignment. - Teams — Agent groups that can be assigned conversations collectively. Capacity applies per agent within a team. See Teams. - Business hours — When business hours are configured, auto-assignment only considers agents during active hours. Capacity limits remain in effect during those windows. See Business Hours. - Automation rules — Conversations can be assigned to specific agents via automation, which bypasses round-robin but still respects capacity awareness in downstream routing. See Automation.

Last updated on Feb 25, 2026

Agent Collision Prevention

Support Portal includes built-in mechanisms to prevent agent collision — the situation where two or more agents unknowingly draft or send responses within the same conversation. In environments with large agent teams or shared queues, uncoordinated replies create confusion for the customer and undermine operational consistency. Operational objective Agent collision prevention addresses two risks: - Duplicate or contradictory responses — When multiple agents reply to the same conversation without awareness of each other, the customer may receive conflicting information. In regulated environments, this can introduce compliance exposure. - Wasted capacity — Every minute an agent spends composing a response that another agent has already sent is time not spent on other conversations. Across a shift, undetected collisions reduce overall throughput. The platform mitigates these risks through conversation ownership assignment and real-time activity indicators. Conversation assignment Each conversation in Support Portal can have a designated assignee. Once an agent is assigned, other team members can see the assignment status in the conversation list and in the conversation detail view, signaling that someone is already responsible for the reply. Agents can assign a conversation to themselves directly from the conversation sidebar using the Assigned Agent selector. Assignment achieves two things: 1. Visibility — The assigned agent's name appears alongside the conversation, so other agents scanning the queue know it is being handled. 2. Filtering — Agents can filter the conversation list by assignment status to focus only on unassigned conversations, reducing the likelihood that two agents open the same item. For teams that want assignment to happen automatically, routing policies and automation rules can assign conversations based on inbox, conversation attributes, or round-robin distribution. See Automation for details on automated assignment actions. Typing indicators Even with assignment in place, situations arise where multiple agents have the same conversation open — for example, during a handoff or when a supervisor reviews an active thread. Support Portal displays a real-time typing indicator whenever another agent begins composing a message in the conversation. The typing indicator appears at the bottom of the message thread in the desktop application and in the mobile application, giving immediate feedback that a colleague is already composing a response. This prevents the most common collision scenario: two agents independently drafting responses without realizing the other is doing the same. How these mechanisms work together Assignment and typing indicators operate as complementary layers: | Mechanism | What it prevents | When it applies | |---|---|---| | Conversation assignment | Two agents picking up the same unassigned conversation from the queue | Before an agent starts working on a conversation | | Typing indicator | Two agents composing simultaneous replies within an already-opened conversation | While agents are actively responding | In practice, assignment is the primary safeguard. It establishes clear ownership so that agents working through a shared queue do not duplicate effort. The typing indicator serves as a secondary safeguard for edge cases where multiple agents have the conversation open at the same time. Recommendations for teams - Enable auto-assignment — Configure routing policies or automation rules to assign incoming conversations automatically. This eliminates the window during which a conversation sits unassigned and is susceptible to multiple agents picking it up. - Use team-based queues — Assign conversations to Teams rather than individual agents when the workload should be distributed across a group. Team assignment still provides visibility while allowing any team member to respond. - Train agents to check assignment status — Agents should verify that a conversation is unassigned before beginning a response, particularly in high-volume environments where multiple agents monitor the same inbox.

Last updated on Feb 25, 2026

Campaigns

Support Portal enables proactive outbound messaging through campaigns — scheduled or condition-based messages delivered to contacts via website live chat or SMS. Rather than waiting for contacts to initiate conversations, campaigns let your organization reach out first with targeted information, service announcements, or engagement prompts. Operational objective Campaigns address two distinct outreach scenarios: - Ongoing campaigns — Continuous, condition-triggered messages delivered through a website live-chat inbox. The platform evaluates visitor behavior (such as time spent on a specific page) and delivers a message when conditions are met. This is well suited to proactive engagement during self-service browsing — for example, a telecom operator offering plan comparison assistance when a visitor lingers on a pricing page, or a government portal prompting citizens to start an application after a period of inactivity on a service eligibility page. - One-off campaigns — Single-execution SMS campaigns sent to a defined audience at a scheduled time. These are appropriate for broadcast communications such as planned maintenance alerts, regulatory deadline reminders, or service change notifications sent to a segmented contact list. Both campaign types are managed from the Campaigns section in the sidebar. Creating an ongoing campaign Ongoing campaigns target visitors on your website live-chat channel. To create one, navigate to Campaigns in the sidebar, select the Ongoing tab, and select Create an ongoing campaign. The campaign configuration interface presents the following parameters: | Field | Description | |---|---| | Title | An internal reference name for the campaign. This is not shown to visitors. | | Message | The outbound message delivered to the visitor when conditions are met. Write this as it will appear in the live-chat widget. | | Select Inbox | The website live-chat inbox through which the message is delivered. Only website-type inboxes appear in this list. | | Sent by | Determines whether the message appears as sent by an agent or by a bot. Choose based on whether you intend the visitor to expect a live reply. | | URL | The page URL where the campaign should activate. Supports both exact URLs and wildcard patterns (see Wildcard URL patterns below). | | Time on page (seconds) | The number of seconds a visitor must remain on the specified URL before the message is triggered. | | Enable campaign | Controls whether the campaign is currently active. Disabled campaigns remain in the list but do not trigger. | After providing the required parameters, select Create to save the campaign. Verify the campaign by visiting the target URL and waiting for the configured duration — the message should appear in the live-chat widget. Wildcard URL patterns Ongoing campaigns support wildcard URL patterns, enabling a single campaign to activate across multiple pages, subdirectories, or subdomains. All URL patterns must begin with http:// or https://. Exact URL matching When you provide a complete URL without wildcards (e.g., https://portal.example.com/services), the campaign activates only on that specific path. A URL with a trailing slash is treated differently from one without — https://portal.example.com/services will match requests to that path with or without a trailing slash, but will not match if additional query or hash parameters are present. To match the path regardless of query parameters or hash fragments, add a trailing slash: https://portal.example.com/services/. This pattern matches all of the following: - https://portal.example.com/services/ - https://portal.example.com/services - https://portal.example.com/services/?lang=en - https://portal.example.com/services/#billing Subdirectory matching Use the * character to match all subdirectories under a given path. For example, https://portal.example.com/* matches: - https://portal.example.com/ - https://portal.example.com/services - https://portal.example.com/services/billing This is useful when a campaign should apply across an entire section of a site — for instance, triggering a support prompt on any page within a citizen services portal. Subdomain matching To match both the root domain and any subdomains, use the {*.}? pattern. For example, https://{*.}?example.com/ matches: - https://example.com - https://portal.example.com - https://www.example.com This pattern is relevant for organizations that operate multiple subdomains under a single brand, such as regional government portals or separate telecom service domains. Creating a one-off campaign One-off campaigns deliver a single SMS message to a targeted audience at a scheduled time. Navigate to Campaigns in the sidebar, select the One Off tab, and select Create a one off campaign. The configuration interface presents the following parameters: | Field | Description | |---|---| | Title | An internal reference name for the campaign. | | Message | The SMS message body. Keep content concise and include any required opt-out language where applicable. | | Select Inbox | The SMS inbox through which the message is delivered. Only SMS-type inboxes appear in this list. | | Audience | The target contact group, defined by one or more Labels. All contacts matching the selected label(s) will receive the message. | | Scheduled time | The date and time at which the campaign executes. | Select Create to save the campaign. It will appear in the One Off campaigns list with its scheduled execution time. Audience targeting with labels One-off campaigns rely on Labels to define the recipient audience. Before creating a campaign, ensure that the relevant contacts have been classified with the appropriate label. For example, a telecom operator sending a network maintenance notification might label affected subscribers with region-north and then target that label in the campaign. A government agency notifying citizens of a document submission deadline could use a label such as pending-renewal. This approach keeps audience management separate from campaign authoring — labels can be applied manually, through imports, or via Automation rules, and the campaign simply references the resulting group. Message content guidelines Campaign messages should be concise, purposeful, and appropriate for the delivery channel: - Ongoing campaigns (live chat) — Write messages that invite interaction. The visitor sees the message in the chat widget and can reply directly. Avoid overly promotional language; instead, offer assistance relevant to the page context. Example: "Looking for help comparing service tiers? An advisor is available to walk you through the options." - One-off campaigns (SMS) — Keep messages within SMS length constraints and include clear calls to action. Where regulatory requirements apply (such as opt-out instructions), ensure compliance in every message. Example: "Your service renewal is due by March 15. Visit portal.example.com/renew or reply HELP to speak with an agent." Managing existing campaigns To modify or remove a campaign, navigate to Campaigns, select the appropriate tab (Ongoing or One Off), and locate the campaign in the list. The edit and delete actions are available at the end of each campaign row. Editing a campaign opens the configuration interface with the current values. Adjust the relevant fields and confirm the changes. Deleting a campaign removes it permanently — this action cannot be undone. For ongoing campaigns, disabling the Enable campaign toggle is preferable to deletion when a campaign should be paused temporarily. Campaigns in operational workflows Campaigns integrate with other platform capabilities to support broader operational processes: - Labels — Define and manage the audience segments used by one-off campaigns. See Labels. - Automation — Use automation rules to apply labels to contacts based on conversation outcomes or contact attributes, which then feed into campaign audiences. See Automation. - Inboxes — Each campaign is tied to a specific inbox. Ensure the appropriate website or SMS inbox is configured before creating campaigns. See Inboxes.

Last updated on Feb 25, 2026

Canned Responses

Support Portal includes a canned response system that allows your organization to define reusable message templates. Agents retrieve these templates during conversations using a shortcode, reducing handling time and ensuring that recurring communications follow a consistent format. Operational objective Canned Responses address two operational concerns: - Response consistency — Standardized templates ensure that agents communicate policy details, procedural instructions, and acknowledgments in the same way, regardless of who handles the conversation. - Handling efficiency — Agents insert a full response in seconds rather than composing it from scratch. For high-volume operations, this directly affects average handling time and throughput. Canned Responses are defined at the workspace level. Every agent in the workspace can access and use any canned response, so templates function as a shared knowledge base for front-line communication. Creating a canned response Navigate to Settings > Canned Responses and select Add Canned Response. A dialog appears with the following fields: | Field | Description | |---|---| | Short Code | A unique identifier used to retrieve the template during a conversation. Minimum two characters. Choose codes that are descriptive and easy to recall (e.g., sla-ack, billing-info, escalation-notice). | | Content | The message body that will be inserted into the conversation editor when the shortcode is invoked. | Select Submit to save the template. The canned response is immediately available to all agents in the workspace. Recommended shortcode conventions Choose shortcodes that reflect operational categories and are easy for agents to recall under time pressure. Examples: | Short Code | Use case | |---|---| | greeting | Standard opening message for new conversations | | escalation-ack | Acknowledgment that a conversation has been escalated to a specialist | | identity-verify | Request for identity verification before processing a sensitive action | | outage-update | Standardized status update during a service disruption | | closure-note | Standard wrap-up message before resolving a conversation | Consistent naming across your template library reduces onboarding time for new agents and improves retrieval speed during live conversations. Editing a canned response Navigate to Settings > Canned Responses, locate the entry, and select the edit icon. Modify the shortcode or message content as needed, then select Submit to save. Updates take effect immediately. Agents who invoke the shortcode after the edit will receive the updated content. Deleting a canned response Navigate to Settings > Canned Responses, locate the entry, and select the delete icon. Confirm the deletion. Removing a canned response does not affect messages that were previously sent using that template. Only future retrieval is affected. Using canned responses in conversations While composing a message, type / in the message editor. This opens a list of all available canned responses. Continue typing to filter by shortcode, or scroll to locate the appropriate template. Select the entry or press Enter to insert its content into the editor. The inserted content is editable before sending. Agents can adjust the template to fit the specific conversation context — for example, adding a reference number or adjusting the phrasing for a particular situation — without modifying the underlying template. Canned responses and operational workflows Canned Responses complement other platform capabilities: - Automation rules — While automation rules handle system-driven actions (such as assigning conversations or applying labels), canned responses equip agents with pre-approved messaging for the human side of those workflows. For example, an automation rule might assign an escalated conversation to a specialist team, and the specialist uses a canned response to acknowledge the escalation to the customer. See Automation. - Macros — Macros execute a sequence of actions in a single step. A macro could apply a label and change assignment, while the agent follows up with the appropriate canned response. See Macros. Together, these tools allow your organization to standardize both the operational handling and the customer-facing communication of routine interactions.

Last updated on Feb 25, 2026

Command Bar

The Command Bar is a keyboard-driven operational shortcut system within Support Portal that provides rapid access to navigation targets and conversation-level actions. It reduces reliance on mouse-based interaction, enabling Agents and administrators to execute operations efficiently during high-volume periods. Operational Objective The Command Bar consolidates navigation and conversation actions into a single search-driven interface. Rather than traversing multiple menus, you can invoke the Command Bar, type a destination or action, and execute it in seconds. Accessing the Command Bar Invoke the Command Bar from any location within the Support Portal Dashboard using the following keyboard shortcut: | Platform | Shortcut | |------------------|-------------| | macOS | Cmd + K | | Windows / Linux | Ctrl + K | The Command Bar presents context-aware suggestions based on your current location in the Dashboard. When invoked from within a conversation view, conversation-specific actions appear first. Navigation Commands The Command Bar supports direct navigation to the following sections. Begin typing the destination name and confirm your selection to navigate immediately. | Destination | Description | |----------------------------|--------------------------------------| | Dashboard Home | Return to the primary Dashboard view | | Contacts | Open the Contacts directory | | Reports > Agent Reports | View per-Agent performance data | | Reports > Label Reports | View label-based report data | | Reports > Inbox Reports | View per-Inbox report data | | Reports > Team Reports | View per-Team report data | | Settings > Agent Settings | Manage Agent configurations | | Settings > Team Settings | Manage Team configurations | | Settings > Label Settings | Manage Labels | | Settings > Canned Response Settings | Manage Canned Responses | | Settings > Application Settings | Manage application integrations | | Settings > Account Settings | Manage workspace-level settings | | Settings > Profile Settings | Manage personal profile | | Notifications | Open the notification center | Conversation Actions When the Command Bar is invoked from a conversation view, the following actions are available: | Action | Description | |---------------------------------|-------------------------------------------------------| | Resolve / Reopen conversation | Transition the conversation to resolved or open state | | Mute / Unmute conversation | Toggle notification suppression for the conversation | | Send email transcript | Dispatch a transcript of the conversation via email | | Assign to Agent | Reassign the conversation to a specific Agent | | Assign to Team | Route the conversation to a specific Team | | Add Label | Apply a Label to the conversation | | Snooze conversation | Temporarily defer the conversation for a set interval | Example: Assigning a Conversation to an Agent 1. Open the Command Bar (Cmd + K or Ctrl + K). 2. Type Assign agent and confirm the selection. 3. The Command Bar presents a list of available Agents. Select the target Agent to complete the assignment. Expected System Behavior - The Command Bar is accessible from all pages within the Support Portal Dashboard. - Search results narrow dynamically as you type, matching against available navigation targets and actions. - Context-aware actions appear only when relevant (conversation actions are only available when viewing a conversation). - All actions executed through the Command Bar take effect immediately; no additional confirmation is required unless the action itself involves a secondary step (such as selecting an Agent during assignment).

Last updated on Feb 25, 2026

Contact Segments

Contact Segments in Support Portal are saved filter configurations applied to the Contacts directory, enabling you to define and persist named groups of contacts based on attribute criteria. Segments function as reusable views that surface relevant contact subsets — such as all contacts from a specific organization, contacts within a geographic region, or contacts associated with a particular Label. Operational Objective Contact Segments provide CRM-style segmentation within the Support Portal workspace. Instead of repeatedly constructing filter queries, you define a segment once and access it from the sidebar on demand. Each segment evaluates its filter criteria dynamically, reflecting the current state of your contact data. For details on managing contact records and available contact attributes, refer to Contacts. Creating a Contact Segment Step 1: Open the Contact Filter Interface Navigate to Contacts from the primary sidebar within the Support Portal Dashboard. Select the Filter control at the top of the contact list. Step 2: Define Filter Criteria The filter configuration interface presents fields for filter type, comparison operator (equal to, not equal to, contains, does not contain), and value. You can chain multiple filter conditions to refine the target contact set. Select Submit to apply the filter criteria. The contact list updates to display only matching records. Step 3: Save the Filtered View as a Segment After validating the filtered contact results, select Save filter in the header of the Contacts page. The system presents a naming dialog. Provide a descriptive segment name that reflects its operational purpose (for example, "Enterprise Accounts — East Region" or "VIP Contacts"). Select Save filter to confirm. Accessing Saved Segments Saved Contact Segments appear in the secondary sidebar under the Segments section. Select any segment entry to immediately load its filtered contact view. Removing a Contact Segment To remove a Contact Segment, open the segment and select Delete Filter from the header area. A confirmation prompt appears; confirm to permanently remove the segment. Expected System Behavior - Segment contents are evaluated dynamically; contacts that no longer match the filter criteria are automatically excluded, and newly matching contacts are included. - Segments are scoped to the individual user's view and do not affect other workspace members. - Deleting a segment removes only the saved filter view. The underlying contact records are not modified. - There is no limit on the number of Contact Segments a user can create.

Last updated on Feb 25, 2026

Contacts

Support Portal maintains a centralized contact registry that records every individual who communicates with your organization. Each contact entry consolidates identity information, conversation history, labels, and custom metadata into a single profile, giving agents and supervisors a unified view regardless of which channel the interaction originated from. Operational objective The Contacts module addresses three operational needs: - Identity consolidation — Every inbound interaction is linked to a contact record, ensuring that agents have immediate context about who they are speaking with and what previous exchanges have occurred. - Proactive outreach — Contacts serve as the starting point for outbound messaging across supported channels, enabling campaign follow-ups, service notifications, or case status updates. - Segmentation and analysis — Filters and saved segments allow teams to group contacts by geography, activity, labels, or Custom Attributes, supporting targeted workflows and operational reporting. Accessing the contact registry Select Contacts from the left sidebar of the Dashboard. The registry displays all recorded contacts in a tabular layout with sortable columns. Adding contacts Contacts enter the registry through three mechanisms. Manual creation Select New Contact in the upper-right corner of the Contacts screen. The creation interface presents the following fields: | Field | Description | |---|---| | Name | Full name of the individual. | | Email | Primary email address. | | Phone Number | Contact phone number, including country code. | | Company Name | Organization the individual belongs to. | Provide the available information and select Submit to save the record. CSV import For bulk onboarding — such as migrating a subscriber database from an existing CRM or provisioning system — use the import function. 1. Select Import in the upper-right corner of the Contacts screen. 2. Choose a CSV file from your local system. The file should include columns for name, email, and phone number at minimum. The platform processes the file and adds each row as a new contact record. Duplicate detection is based on email address. Automatic capture Contacts are also created automatically when an individual provides identifying information during a conversation: - Pre-chat forms — When a pre-chat form is enabled on a channel, any visitor who submits their details is registered as a contact before the conversation begins. See Pre Chat Form for configuration details. - Channel greetings — If a visitor responds to a greeting message with an email address, the platform creates a contact record and associates it with the ongoing conversation. These automatic mechanisms ensure that the contact registry grows organically as your organization handles more interactions, without requiring manual data entry. Viewing and managing a contact profile Select any contact name in the registry to open the contact detail panel. This panel presents: - Identity fields — Name, email, phone number, company, and location. - Conversation history — A chronological list of all conversations associated with the contact. - Labels — Any labels applied to the contact for classification purposes. See Labels. - Notes — Free-text annotations added by agents or supervisors. Contact notes Notes provide a mechanism for recording contextual information that does not belong in a conversation thread — such as a summary of a phone call, a record of an in-person meeting, or an internal decision regarding the contact's account. To add a note: 1. Open the contact profile by selecting the contact name. 2. Enter the note content in the text field at the bottom of the notes section. Rich text formatting is supported. 3. Select Add or press Cmd + Enter (macOS) / Ctrl + Enter (Windows/Linux) to save. Notes can be deleted individually if they are no longer relevant. Outbound messaging From the contact profile, select New Message to initiate an outbound conversation. The following channel types support outbound contact from the Contacts interface: | Channel | Requirement | |---|---| | Website | Contact must be identified via HMAC verification. | | Email | A valid email address must be associated with the contact. | | SMS | A phone number must be associated with the contact. | | WhatsApp | A phone number with an active WhatsApp account is required. | This capability is particularly useful for proactive service scenarios — for example, a telecom operator notifying a subscriber about a planned maintenance window, or a government agency sending a follow-up regarding a submitted application. Sorting contacts Each column in the contact registry supports sorting. Select the sort icon in any column header to reorder the list: | Column | Sort behavior | |---|---| | Name | Alphabetical | | Email | Alphabetical | | Phone Number | Numerical | | Company | Alphabetical | | City | Alphabetical | | Country | Alphabetical | | Last Activity | Chronological (most recent first or last) | Sorting helps agents and supervisors locate specific records quickly — for instance, identifying all contacts from a particular country or reviewing recently active subscribers. Filtering contacts The contact registry supports advanced filtering to isolate subsets of contacts based on specific criteria. Applying filters Select Filter at the top of the Contacts screen, then choose a filter attribute from the dropdown. The following attributes are available: | Filter attribute | Description | |---|---| | Contact Name | Match by full or partial name. | | Contact Email | Match by email address. | | Phone Number | Match by phone number. | | Contact Identifier | Match by the platform-assigned identifier. | | Country | Match by country. | | City | Match by city. | | Created At | Match by the date the contact was first recorded. | | Last Activity | Match by the date of the most recent interaction. | | Custom Attributes | Match by any Custom Attributes configured in your workspace. | Set the comparison operator (e.g., "Equal to", "Not equal to", "Contains") and specify the target value. Multiple filters can be combined using AND / OR operators to construct more specific queries — for example, isolating contacts in a specific region who have been inactive for more than 90 days. Select Submit to apply the filter. The registry updates to display only matching contacts. Saving filters as segments When a filter combination represents a recurring operational need, save it as a named segment for instant reuse. 1. After applying one or more filters, select Save Filter at the top of the filtered results. 2. Provide a descriptive name for the segment (e.g., "Enterprise accounts — Northern region" or "Inactive subscribers — Q4"). 3. Select Save Filter to confirm. Saved segments appear in the left sidebar under the Contacts section. Select any segment to instantly apply its filter criteria. Modifying or clearing filters To adjust an active filter set, select Filter again. The filter panel reopens with the current criteria pre-populated. Modify the conditions as needed and select Submit, or clear all filters to return to the unfiltered registry view. Grouping contacts by labels Contacts can be tagged with Labels to support classification workflows. From the Contacts screen, use the Tagged with selector to display only contacts associated with a specific label. This is useful for operational grouping — for example, tagging all contacts involved in a pilot program, or flagging contacts who require special handling due to regulatory requirements. For more on label management, see Labels. Integration with other platform capabilities Contacts interact with several other areas of the platform: - Conversations — Every conversation is linked to a contact record. Agents see full contact context in the conversation side panel. See Conversation Lifecycle. - Custom Attributes — Extend contact profiles with organization-specific fields such as account number, subscription tier, or service region. Custom Attributes are also available as filter criteria. See Custom Attributes. - Automation — Contact properties can serve as conditions in automation rules — for example, automatically assigning conversations from contacts in a specific country to a regional support team. See Automation.

Last updated on Feb 25, 2026

Conversation Continuity via Email

Support Portal includes a conversation continuity mechanism that transitions live chat interactions to email when a visitor leaves the session before the exchange is resolved. Instead of losing the conversation, the platform automatically delivers a summary and any pending agent replies to the visitor's email address, allowing both parties to continue the thread without starting over. Operational objective In enterprise environments, visitors frequently leave a live chat session before an agent responds. A government citizen navigating a service portal may close the browser after submitting a question. A telecom customer may lose connectivity or switch devices mid-conversation. Without a continuity mechanism, these interactions become dead ends — the agent's reply goes unseen, and the visitor must repeat their request through a new session. Email continuity solves this by ensuring that every agent reply reaches the visitor, regardless of whether their chat session is still active. When the visitor replies to the email, the response flows back into the same conversation thread in the agent's dashboard, preserving full context. When email fallback triggers The platform transitions a conversation to email when both of the following conditions are met: - The visitor has left the chat session — the browser tab is closed, the visitor has navigated away, or the session has timed out. - An agent sends a reply after the visitor has departed — the reply cannot be delivered through the live chat widget, so the platform falls back to email delivery. If the visitor is still connected to the chat session, replies are delivered in real time through the widget as normal. Email continuity only activates when the live channel is no longer available. Prerequisite: a known email address For email continuity to function, the platform must have an email address associated with the visitor's contact record. Support Portal provides three methods to capture this information, each suited to different operational scenarios. Programmatic capture via the SDK When the visitor's identity is already known — for example, because they are logged into a customer portal or authenticated service — their email address can be passed directly to the platform using the setUser method in the Support Portal SDK. This is the most seamless approach, as the visitor is never prompted for information they have already provided during authentication. This method is particularly relevant for government portals and telecom self-service environments where visitors are typically authenticated before reaching the chat interface. See Sdk Setup for SDK configuration details. Collection through the pre-chat form When a pre-chat form is enabled on the inbox, visitors provide their name and email address before the conversation begins. This ensures email continuity is available from the first message. The pre-chat form is configured at the inbox level. See Inbox Configuration for setup instructions. Automatic email collection prompt When no pre-chat form is active and the visitor's email is not already known, the platform displays an email collection prompt within the chat widget. This prompt requests the visitor's email address so that the conversation can continue if they leave. When an AI Module (Altores Intelligence) is enabled on the inbox, the email collection prompt is suppressed. The AI Module handles the conversation directly, including outside business hours. The email prompt is only displayed if the AI Module hands the conversation off to a human agent or if no AI Module is configured for the inbox. Visitor experience When a visitor leaves the chat session and an agent subsequently replies, the platform sends an email containing a summary of the conversation along with the agent's response. The visitor can reply directly to this email. Their reply is routed back into the original conversation thread — no new conversation is created, and no context is lost. This is especially important in regulated environments where conversation history must remain intact for audit and compliance purposes. A telecom customer who closes their browser mid-complaint receives the agent's follow-up in their inbox and can continue the exchange at their convenience, with the full thread preserved. Agent experience From the agent's perspective, email continuity is transparent. When a visitor replies via email, the message appears in the existing conversation thread on the agent's dashboard. An email indicator icon on the message bubble identifies that the reply originated from email rather than the live chat widget. Agents do not need to switch tools or open a separate email client. The conversation remains unified in the dashboard regardless of which channel the visitor used to respond. Configuration Conversation continuity via email requires a functioning email channel configuration on the Support Portal instance. For self-hosted deployments, ensure that outbound email delivery is properly configured before relying on this feature. Verify the following operational requirements: | Requirement | Details | |---|---| | Email channel | An active email sending configuration must be in place for the workspace. | | Contact email address | The visitor's email must be captured through one of the three methods described above. | | Inbox assignment | The conversation must belong to an inbox that supports live chat. Email continuity applies to the website live chat channel. | For self-hosted deployment configuration, consult your infrastructure documentation or contact Altores support. Relationship to other features Email continuity interacts with several other platform capabilities: - Business hours — When agents are unavailable outside business hours and the visitor leaves a message, email continuity ensures the agent's eventual reply still reaches the visitor. See Business Hours. - Automation rules — Automation can apply labels or reassign conversations based on whether the visitor has an email address on file, enabling differentiated handling for identified versus anonymous visitors. See Automation. - CSAT surveys — Customer satisfaction surveys sent after conversation resolution rely on the same email address used for continuity. Ensuring accurate email capture improves CSAT response rates. See Customer Satisfaction (CSAT) Surveys.

Last updated on Feb 25, 2026

Conversation Filters

Support Portal provides a filter engine that lets agents and supervisors narrow the conversation list to specific operational segments. Filters can target conversations by status, assignee, team, label, inbox, or any custom attribute defined in your workspace — and multiple criteria can be combined with logical operators to build precise queries. Operational objective Conversation filters address three operational needs: - Prioritization — Surface conversations that require immediate attention, such as those tagged with an SLA-breach label or assigned to an escalation team. - Workload segmentation — Allow agents to focus on a defined subset of conversations, for example all open conversations in a specific inbox or assigned to a particular team. - Operational monitoring — Enable supervisors to audit conversation distribution, identify bottlenecks, and verify that routing policies are working as intended. Available filter criteria The following filter types are available: | Filter type | Description | |---|---| | Status | Conversation state: open, resolved, pending, or snoozed. | | Assignee | The agent currently assigned to the conversation. | | Inbox | The channel or inbox through which the conversation was initiated. | | Team | The team assigned to handle the conversation. | | Conversation Identifier | The unique numeric ID of a conversation. | | Labels | One or more labels applied to the conversation. See Labels. | | Campaigns | The campaign that originated the conversation. | | Created at | The date the conversation was created. | | Last activity | The date of the most recent message or event in the conversation. | | Browser Language | The language detected from the contact's browser. | | Country | The country associated with the contact. | | Referrer Link | The URL from which the contact arrived at the conversation widget. | | Custom Attributes | Any custom attribute defined at the workspace level. | Each filter type supports a set of operators — typically Equal to, Not equal to, Present, and Not present — depending on the data type of the field. Applying filters To filter the conversation list, select the filter icon at the top of the conversation list. The filter configuration panel opens. Select a filter type from the first dropdown, choose an operator, and specify a value. Select Apply Filters to update the conversation list. The list updates immediately, showing only conversations that match the specified criteria. Combining filters with AND / OR operators Multiple filter criteria can be combined to construct targeted queries. Each additional filter row is joined to the previous row by a logical operator: - AND — Requires all conditions to be true. Use this to narrow results progressively. - OR — Requires at least one condition to be true. Use this to broaden results across multiple categories. To add a filter row, select the operator button (AND or OR) below the current row. There is no limit to the number of criteria in a single query. Enterprise example A supervisor monitoring SLA compliance for the escalation team might configure the following filter: | Row | Filter type | Operator | Value | Logical join | |---|---|---|---|---| | 1 | Status | Equal to | Open | — | | 2 | Team | Equal to | Escalation | AND | | 3 | Labels | Equal to | sla-breach | AND | This returns all open conversations assigned to the escalation team that have been flagged with the sla-breach label — a focused view for identifying conversations requiring immediate resolution. An alternative query using OR logic could surface conversations across multiple priority categories: | Row | Filter type | Operator | Value | Logical join | |---|---|---|---|---| | 1 | Labels | Equal to | sla-breach | — | | 2 | Labels | Equal to | escalation-required | OR | This returns any conversation tagged with either label, providing a broader view of items requiring supervisory attention. Saving filters as folders Filter configurations that are used repeatedly can be saved as custom folders. Saved folders appear in the left sidebar alongside the default conversation views, providing one-click access to predefined segments. To save a filter as a folder: 1. Configure the desired filter criteria as described above. 2. Select Save Filter in the filter panel. 3. Provide a name for the folder (e.g., "SLA Breaches — Escalation Team" or "Pending — Billing Disputes"). The saved folder appears in the sidebar. Selecting it applies the stored filter criteria to the conversation list without requiring manual reconfiguration. Managing saved folders To rename or delete a saved folder, right-click the folder in the sidebar or use the context menu. Removing a folder does not affect the underlying conversations — it only removes the saved filter view. Recommended folder examples | Folder name | Filter criteria | Use case | |---|---|---| | Unassigned — High Priority | Status = Open, Assignee = Not present | Monitor conversations that have not yet been routed to an agent. | | SLA Breach — Open | Status = Open, Labels = sla-breach | Track conversations exceeding response time thresholds. | | Escalation Queue | Team = Escalation, Status = Open | Dedicated view for the escalation team's active workload. | | Regulatory Inquiries | Labels = regulatory-inquiry | Isolate compliance-related conversations for audit purposes. | Clearing filters To remove all active filters and return to the default conversation list, select Clear Filters in the filter panel. Clearing filters does not affect saved folders. Previously saved filter configurations remain available in the sidebar.

Last updated on Feb 25, 2026

Conversation Folders

Conversation Folders in Support Portal are saved filter views that persist as sidebar entries, providing immediate access to specific subsets of conversations. They enable supervisors and Agents to maintain standing views of operationally significant conversation groups — such as all escalated tickets for a particular Team, or all unresolved conversations older than 24 hours. Operational Objective Rather than re-applying filter criteria each session, Conversation Folders allow you to define a filter configuration once and access its results on demand. Each folder dynamically evaluates its filter criteria, ensuring the conversation list always reflects current data. For details on available filter types and operators, refer to Conversation Filters. Creating a Conversation Folder Step 1: Open the Filter Interface From the conversation list view within the Support Portal Dashboard, select the filter icon at the top of the conversation list panel. Step 2: Define Filter Criteria The filter configuration interface presents fields for filter type, comparison operator (equal to, not equal to, present, not present), and value. Combine multiple filter conditions as needed to define the target conversation set. Apply the configured filters by selecting Apply Filters. The conversation list updates to display only matching results. Step 3: Save the Filtered View as a Folder After verifying the filtered results, select Save at the top of the conversation list panel. Step 4: Name the Folder The system presents a naming dialog. Provide a descriptive name that reflects the operational purpose of the folder (for example, "Escalated — Billing Team" or "Unresolved > 24h"). Confirm to create the folder. Accessing Saved Folders Saved Conversation Folders appear in the primary sidebar under the Folders section. Select any folder to immediately load its filtered conversation view. Removing a Conversation Folder To remove a Conversation Folder, locate the folder entry in the sidebar and select the delete icon adjacent to its name. A confirmation prompt appears; select Yes, Delete to permanently remove the folder. Expected System Behavior - Folder contents are evaluated dynamically; conversations that no longer match the filter criteria are automatically excluded. - Each user's folders are scoped to their own view and do not affect other users in the workspace. - Deleting a folder removes only the saved filter view. The underlying conversations are not affected. - There is no limit on the number of Conversation Folders a user can create.

Last updated on Feb 25, 2026

Conversation Sorting

Support Portal provides multiple sorting modes that control the order in which conversations appear in the agent workspace. By selecting the appropriate mode, agents and supervisors can ensure that the most operationally relevant conversations surface first — whether that means the newest interaction, the oldest unresolved request, or the most critical SLA-sensitive issue. Operational objective Sorting determines how the platform ranks conversations within a given view. The correct sorting strategy depends on your team's operational goals: - Responsiveness — Surface conversations with the most recent customer activity so agents engage with active discussions first. - Fairness — Order conversations by creation time to ensure older requests are not overlooked. - Criticality — Rank conversations by assigned priority level, placing urgent and high-priority items at the top of the queue. - SLA compliance — Identify conversations that have been waiting the longest for a response, reducing the risk of SLA breaches. Sorting applies to the current conversation list view and works alongside filters, labels, and assignment rules. It does not change the underlying data — only the display order. Available sorting modes The agent workspace offers four sorting modes, accessible from the sort control above the conversation list. Last activity Conversations are ordered by the timestamp of their most recent event — typically the last incoming or outgoing message, but also status changes and internal notes. | Behavior | Detail | |---|---| | Order | Most recently active conversation appears first | | Timestamp source | Last message, status update, or activity event | | Use case | Monitoring active discussions in real time | This mode is the default. It ensures agents see ongoing conversations that require immediate follow-up, rather than older threads with no recent movement. Creation time Conversations are ordered by the timestamp at which they were initially created, regardless of subsequent activity. | Behavior | Detail | |---|---| | Order | Most recently created conversation appears first | | Timestamp source | Conversation creation timestamp | | Use case | Reviewing the intake queue; ensuring older conversations are addressed | When reversed (oldest first), this mode supports a first-in-first-out workflow — useful for regulated environments where processing order matters. Priority Conversations are ranked by their assigned priority level. The hierarchy follows a fixed order: 1. Urgent — appears at the top 2. High 3. Medium 4. Low 5. None — conversations without an assigned priority appear last | Behavior | Detail | |---|---| | Order | Highest severity first; unassigned priority at the bottom | | Timestamp source | Not time-based — purely rank-based | | Use case | Ensuring critical issues receive attention before routine inquiries | Within the same priority tier, conversations are ordered by last activity. This means two urgent conversations are still distinguishable by recency. Enterprise example: A government helpdesk assigns Urgent priority to citizen complaints with regulatory deadlines. When agents switch to priority sorting, these conversations surface above general inquiries — ensuring compliance targets are met before lower-severity requests are handled. Waiting for response Conversations are ordered by how long they have been waiting for an agent reply. This mode focuses exclusively on conversations where the most recent message was from the contact, not the agent. | Behavior | Detail | |---|---| | Order | Longest-waiting conversation appears first | | Timestamp source | Time elapsed since the last incoming message with no agent reply | | Use case | Reducing response delays; preventing SLA breaches | Conversations where the agent has already replied — or where the last activity was an outgoing message — are placed at the bottom of the list. Enterprise example: A telecom operator with a 30-minute first-response SLA uses this mode during peak hours. Agents immediately see which conversations are closest to breaching the SLA threshold, allowing them to address the most time-sensitive items first. How sorting interacts with other features Sorting works in combination with several other workspace capabilities: | Feature | Interaction | |---|---| | Filters | Sorting applies within the filtered result set. For example, filtering by a specific label and sorting by priority shows only labeled conversations, ranked by severity. | | Assignment | Sorting applies equally to "Mine," "Unassigned," and "All" conversation views. | | Labels | Labels do not affect sort order directly, but labeled sidebar views respect the active sorting mode. See Labels. | | Priority | Priority values are set per conversation — either manually or through automation rules. The priority sorting mode reads these values. See Automation. | Choosing a sorting strategy The appropriate sorting mode depends on the team's operational context: | Scenario | Recommended mode | |---|---| | General support desk during business hours | Last activity | | Queue-based processing with SLA requirements | Waiting for response | | Incident management or escalation handling | Priority | | End-of-day review of unresolved intake | Creation time | Teams operating under strict SLA policies should consider combining the Waiting for response mode with automation rules that assign priority levels based on elapsed time. This ensures that conversations approaching an SLA threshold are both flagged and surfaced at the top of the queue.

Last updated on Feb 25, 2026

Custom Attributes

Support Portal includes a set of standard fields for conversations and contacts — name, email address, phone number, and location among them. Custom Attributes extend this data model with fields specific to your organization, allowing agents and automation rules to capture and act on operational context that standard fields do not cover. Operational objective Custom Attributes address three requirements: - Data model extension — Attach structured metadata to conversations or contacts without modifying the underlying platform schema. Examples include contract identifiers, SLA tiers, service regions, or regulatory classification codes. - Contextual decision-making — Agents see custom fields directly in the conversation or contact side panel, providing the context needed to handle interactions according to organizational policy. - Automation and segmentation — Custom Attributes are available as conditions and actions in automation rules, enabling routing, classification, and escalation based on organization-specific data points. See Automation. Standard vs. custom attributes Standard attributes (name, email, phone, location) are populated automatically by the platform when data is available. Custom Attributes are defined by administrators and populated manually by agents or programmatically through the SDK or API. Once defined, a Custom Attribute is available across the workspace for all teams and agents. Creating a custom attribute Navigate to Settings > Custom Attributes and select Add Custom Attribute. The configuration interface presents the following parameters: | Parameter | Description | |---|---| | Applies to | Determines whether the attribute is associated with Conversation or Contact records. This cannot be changed after creation. | | Display Name | The label shown to agents in the side panel. Use a clear, recognizable name (e.g., "Contract ID", "SLA Tier", "Service Region"). | | Key | A unique machine-readable identifier used in API calls, SDK methods, and automation rules. Keys must be unique within the workspace. | | Description | An optional explanation of what the attribute represents. Helps maintain consistent usage across teams. | | Type | The data type for the attribute value. Available types: Text, Number, Link, Date, List, and Checkbox. | Select Create to save the attribute. A confirmation message indicates the attribute has been registered. The attribute immediately becomes available in the relevant side panel section (Conversation Information or Contact Attributes). Each key must be unique within the workspace. Attempting to create a second attribute with an identical key produces a validation error. Using custom attributes on conversations Conversation-type Custom Attributes appear in the Conversation Information section of the conversation side panel. Applying an attribute: 1. Open a conversation and locate the Conversation Information section in the side panel. 2. Select the + control to expand the attribute picker. 3. The picker lists all conversation-type Custom Attributes defined in the workspace. Use the search field to locate a specific attribute, or browse the list and select one. Once an attribute is added to a conversation, its input field appears in the side panel. The field type matches the attribute definition — a date picker for Date attributes, a dropdown for List attributes, a checkbox for Checkbox attributes, and a text or numeric input for the remaining types. To modify a value, select the attribute field and update it directly. To remove, copy, or edit an attribute entry, hover over the attribute to reveal the available actions. Enterprise use cases | Attribute | Type | Purpose | |---|---|---| | Contract ID | Text | Link the conversation to a specific service agreement for SLA tracking | | SLA Tier | List | Classify the expected response and resolution time targets | | Region | List | Identify the service region for routing or compliance purposes | | Escalation Reason | Text | Capture the reason a conversation was escalated to a specialist team | Using custom attributes on contacts Contact-type Custom Attributes appear in the Contact Attributes section of the contact side panel. The process for applying and populating contact attributes mirrors the conversation workflow described above: expand the section, select an attribute from the picker, and provide a value. Contact attributes persist across all conversations with that contact, making them suitable for long-lived metadata such as account type, organization name, or subscriber tier. Enterprise use cases | Attribute | Type | Purpose | |---|---|---| | Account Type | List | Distinguish between enterprise, government, and individual contacts | | Subscriber Tier | List | Identify the service level associated with the contact's subscription | | Organization ID | Text | Reference an external CRM or ERP record for the contact's organization | | Onboarding Date | Date | Track when the contact completed initial setup or provisioning | Programmatic management via SDK Custom Attributes on contacts can also be managed programmatically using the web widget SDK. This is useful for pre-populating contact metadata from an external system when a visitor initiates a conversation. Setting attributes Use the setCustomAttributes method to assign one or more attribute values: window.$chatwoot.setCustomAttributes({ account_type: "government", subscriber_tier: "priority", organization_id: "GOV-2847-A" }); Keys must correspond to Custom Attributes already defined in Settings > Custom Attributes. Values should match the expected data type for each attribute. Removing attributes Use deleteCustomAttribute to remove a specific attribute value from the current contact: window.$chatwoot.deleteCustomAttribute("subscriber_tier"); Attributes set through the SDK appear in the contact side panel alongside manually entered values. Integration with automation and reporting Custom Attributes extend the conditions available in automation rules and the filters available across the platform: - Automation rules — Use Custom Attributes as conditions to trigger actions based on organization-specific data. For example, an automation rule could assign conversations with an SLA Tier of "Critical" to a dedicated team. See Automation. - Conversation filters — Custom Attributes are available as filter criteria in the conversation list, enabling agents and supervisors to isolate conversations by operational metadata. - Contact segmentation — Filter the contact list by Custom Attribute values to identify groups of contacts with shared characteristics. For reporting on conversation metadata, see Reports.

Last updated on Feb 25, 2026

Keyboard Shortcuts

Support Portal provides a set of keyboard shortcuts designed to accelerate routine operations for Agents working in high-volume conversational environments. These shortcuts reduce context-switching overhead by enabling direct execution of common actions without mouse interaction. Operational Objective Keyboard shortcuts allow Agents to perform frequent tasks — such as resolving conversations, toggling interface panels, and navigating between views — with minimal input. Consistent use of shortcuts can significantly reduce average handling time per conversation. Viewing Available Shortcuts To display the complete list of keyboard shortcuts at any time, use one of the following methods: | Method | Action | |---------------------|---------------------------------------------------------------------| | Keyboard shortcut | Press Cmd + / (macOS) or Ctrl + / (Windows / Linux) | | Profile menu | Select Keyboard Shortcuts from the Profile Settings menu | Shortcut Reference The following tables enumerate the available keyboard shortcuts, grouped by functional category. Global Navigation | Shortcut (macOS) | Shortcut (Windows/Linux) | Action | |-------------------|--------------------------|-------------------------------------| | Cmd + / | Ctrl + / | Display keyboard shortcuts overlay | | Cmd + K | Ctrl + K | Open Command Bar | Conversation Actions | Shortcut | Action | |-----------|----------------------------------------------| | Alt + L | Toggle the conversation sidebar panel | | Alt + B | Toggle the contact information sidebar | | Alt + E | Open the emoji selector in the reply editor | | Alt + A | Open the attachment selector | | Alt + N | Navigate to the next conversation in the list | | Alt + P | Navigate to the previous conversation in the list | | Alt + R | Open the rich-text formatting toolbar | | Alt + M | Resolve the active conversation | Message Composition | Shortcut (macOS) | Shortcut (Windows/Linux) | Action | |---------------------|--------------------------|-------------------------------------------| | Cmd + Enter | Ctrl + Enter | Send the message in the reply editor | | Cmd + Shift + A | Ctrl + Shift + A | Toggle between Reply and Note mode | Expected System Behavior - Keyboard shortcuts are active across all pages of the Support Portal Dashboard where the corresponding action is available. - Shortcuts that act on a conversation (resolve, navigate, toggle panels) require an active conversation to be selected. - The shortcuts overlay can be dismissed by pressing Esc or selecting anywhere outside the overlay. - Shortcut bindings are not configurable; they follow the default mappings listed above. For additional keyboard-driven productivity, refer to the Command Bar documentation at Command Bar for search-based navigation and action execution.

Last updated on Feb 25, 2026

Labels

Support Portal provides a label system for classifying conversations. Labels allow your team to tag conversations by topic, urgency, department, or any operational category relevant to your organization. Operational objective Labels serve three primary functions: - Classification — Group conversations by type, topic, or business process so they can be identified at a glance. - Filtering and routing — Labels appear in the sidebar and can be used as filter criteria, enabling agents to focus on specific conversation subsets. They also serve as conditions and actions in automation rules. - Reporting — Label-based reports provide insight into conversation volume and resolution performance by category, helping identify process gaps or training needs. Labels are defined at the workspace level and are available to all teams and agents. Creating a label Navigate to Settings > Labels and select Add Label. Complete the following fields: | Field | Description | |---|---| | Label Name | A short identifier for the category. Only letters, numbers, hyphens, and underscores are allowed. | | Description | A brief explanation of what the label represents. This helps other team members apply labels consistently. | | Color | A color for visual distinction in the conversation list and sidebar. | | Show on sidebar | When enabled, the label appears in the left sidebar for one-click filtering. | Select Create to save the label. The label immediately becomes available in the conversation sidebar, the automation rule builder, and report filters. Recommended naming conventions Use names that reflect operational categories rather than ad-hoc descriptions. Examples: | Label | Purpose | |---|---| | escalation-required | Conversations requiring supervisor review | | regulatory-inquiry | Requests related to compliance or regulatory matters | | billing-dispute | Payment or invoice-related issues | | sla-breach | Conversations that exceeded SLA thresholds | | onboarding | New customer setup and configuration questions | Consistent naming improves the reliability of automation rules and label-based reports. Editing a label Navigate to Settings > Labels, locate the label, and select the edit icon. Modify the name, description, color, or sidebar visibility as needed, then select Edit to save changes. Renaming a label updates it across all conversations where it is currently applied. Deleting a label Navigate to Settings > Labels, locate the label, and select the delete icon. Confirm the deletion. Deleting a label removes it from all conversations. This action cannot be undone. Using labels in conversations To apply a label to a conversation, open the conversation and use the label selector in the side panel. Multiple labels can be assigned to a single conversation. Labels assigned to conversations are visible in the conversation list, making it possible to scan and prioritize work without opening each conversation individually. Labels in automation and reporting Labels integrate with two other platform capabilities: - Automation rules — Labels can be used as conditions (e.g., "if label equals escalation-required") and as actions (e.g., "add label sla-breach"). This enables automated classification based on conversation properties. See Automation. - Reports — The Labels report provides metrics such as conversation volume, first response time, and resolution time grouped by label. Use this to measure operational performance across categories. See Reports.

Last updated on Feb 25, 2026

Macros

Support Portal provides a macro system that allows agents to bundle multiple conversation actions into a single reusable sequence. Instead of performing each step manually — assigning a team, applying a label, sending a response, changing status — agents execute one macro that carries out the entire workflow in sequence. Operational objective Macros address a common operational challenge: repetitive multi-step processes that agents perform throughout the day. Defining these as named sequences reduces handling time, eliminates missed steps, and ensures consistent execution across the team. Typical use cases include: - Escalation workflows — Reassign the conversation to a specialist team, apply an escalation label, and notify the contact with a status message. - Compliance handoff — Assign a regulatory review team, attach a compliance notice, label the conversation for audit tracking, and snooze until review is complete. - Routine closures — Send a standard resolution message, apply a category label, and resolve the conversation. Macros can be scoped as personal (visible only to the creating agent) or public (available to all agents in the workspace). Creating a macro Navigate to Settings > Macros and select Add a new macro. The macro configuration interface opens with two areas: an action builder on the left and a properties panel on the right. Naming the macro In the right panel, provide a descriptive name for the macro. Choose a name that communicates the workflow's purpose — agents will reference this name when selecting macros from the conversation sidebar. Defining actions Each macro consists of one or more sequential actions. Select an action from the dropdown and configure its parameters. Once an action is configured, add the next action in the sequence. The following actions are available: | Action | Description | |---|---| | Assign an Agent | Route the conversation to a specific agent. | | Assign a Team | Route the conversation to a designated team queue. | | Add Label | Apply one or more labels to the conversation for classification and filtering. | | Send Email Transcript | Dispatch the conversation transcript to a specified email address. | | Send Attachment | Attach a file to the conversation. | | Send a Message | Post a predefined message into the conversation. | | Mute Conversation | Suppress notifications for the conversation. | | Snooze Conversation | Temporarily remove the conversation from the active queue until a specified time. | | Resolve Conversation | Set the conversation status to resolved. | Actions execute in the order they are defined. Position actions deliberately — for example, assign a team before sending a notification message so the receiving team sees the message upon pickup. Setting visibility Each macro has a visibility scope that controls who can access it: | Visibility | Behavior | |---|---| | Private | Only the agent who created the macro can view and execute it. | | Public | All agents in the workspace can view and execute the macro. | Set visibility to Public when the macro represents a standardized workflow that the entire team should follow. Use Private for personal productivity shortcuts that are specific to an individual agent's responsibilities. Saving Select Save macro to store the configuration. The macro becomes immediately available for execution. Enterprise workflow examples Escalation macro A telecom support team can define a macro that handles tier-2 escalations: 1. Assign a Team — Route to the Network Operations team. 2. Add Label — Apply escalation-required. 3. Send a Message — Post: "This conversation has been escalated to our specialist team. You will receive an update within the SLA window." 4. Snooze Conversation — Snooze for 4 hours to allow the specialist team time to review. This ensures every escalation follows the same sequence, with no steps omitted. Compliance handoff macro For regulated environments where certain inquiries require formal review: 1. Assign a Team — Route to the Compliance Review team. 2. Add Label — Apply regulatory-inquiry. 3. Send Attachment — Attach the standard compliance acknowledgment document. 4. Send a Message — Post: "Your inquiry has been forwarded to our compliance team for review. We will respond within the regulatory timeframe." 5. Mute Conversation — Suppress notifications while the review is pending. This macro guarantees that compliance-sensitive conversations are routed correctly and that the contact receives the required acknowledgment. Executing a macro Macros are executed from the conversation sidebar. Open a conversation and locate the Macros section in the right panel. Expand it to display all available macros — both personal and public. Previewing before execution Select the information icon next to a macro to preview its action sequence. The preview displays each action in order, allowing the agent to confirm the macro is appropriate for the current conversation before running it. Running the macro Select the execute button (play icon) to run the macro. All actions execute in the defined sequence. Success confirmations appear for each completed action, providing visibility into what the macro performed. Editing and deleting macros Navigate to Settings > Macros to manage existing macros. Locate the target macro in the list and use the corresponding edit or delete control. - Editing — Opens the configuration interface with the current action sequence and settings. Modify actions, reorder steps, or update visibility as needed, then save. - Deleting — Removes the macro permanently. This does not affect conversations where the macro was previously executed — those actions have already been applied. Related capabilities Macros complement other workflow features in Support Portal: - Labels — Macros frequently apply labels as part of their action sequence. Define a consistent label taxonomy to maximize macro effectiveness. See Labels. - Automation — Where macros are agent-initiated, automation rules execute automatically based on conversation conditions. Use both together for comprehensive workflow coverage. See Automation. - Canned Responses — For scenarios that only require a templated reply without additional actions, canned responses offer a lighter alternative. See Canned Responses. - Teams — Macros that include team assignment depend on properly configured team structures. See Teams.

Last updated on Feb 25, 2026

Message Signature

Support Portal allows each agent to define a personal message signature — a structured sign-off appended to outbound messages. Unlike email-only signature systems, message signatures in Support Portal apply across all connected inboxes, providing consistent agent identification regardless of the communication channel. Operational objective Message signatures serve two primary functions: - Agent identification — Each outbound message includes the agent's name, role, and relevant contact information, reinforcing professional communication standards across all channels. - Operational consistency — A standardized signature format across the team ensures that all customer-facing communication meets organizational presentation requirements without relying on agents to manually compose sign-offs. Signatures are configured per agent and managed through personal settings. There is no workspace-level override — each agent maintains their own signature content. Configuring a message signature Navigate to the profile icon at the bottom-left of the dashboard, then select Personal Settings. Scroll to the Personal message signature section. The rich text editor supports the following formatting capabilities: | Capability | Details | |---|---| | Text formatting | Bold, italic, underline, and other standard formatting options | | Links | Embed clickable URLs for team pages, scheduling tools, or contact forms | | Inline images | Upload a logo or headshot (subject to channel limitations — see below) | Compose the signature content, then select Save message signature to apply. Recommended signature structure For regulated environments and enterprise deployments, consider including: | Element | Example | |---|---| | Full name | Alex Moreira | | Role / department | Senior Support Engineer — Network Operations | | Direct contact | +31 20 555 0142 | | Organization | Altores B.V. | Keep signatures concise. Excessively long signatures consume message space and reduce readability, particularly on messaging channels where screen real estate is limited. Signature behavior during conversations Once configured, the signature is enabled by default. It appends automatically to every outbound message in the reply editor. Agents retain full control over the signature on a per-message basis. Sending with signature When the signature is active, it appears below the message composition area. No additional action is required — the signature is included automatically when the agent sends the message. Editing the signature before sending The signature content in the reply editor is fully editable on a per-message basis. An agent can remove a phone number, adjust a line, or clear the signature entirely for a specific message without affecting the saved template. Subsequent messages revert to the saved signature. Disabling the signature To suppress the signature for the current session, select the signature toggle in the message editor toolbar. When disabled, outbound messages are sent without the appended signature until the agent re-enables it. Channel limitations Message signatures render differently depending on the channel's API capabilities. The following distinction applies: | Channel type | Signature rendering | |---|---| | Email inboxes | Full signature including formatted text and inline images | | Website live chat | Full signature including formatted text and inline images | | API inboxes | Full signature including formatted text and inline images | | All other channels (SMS, WhatsApp, Telegram, etc.) | Text content only — inline images are stripped by the channel provider | When designing signatures for a multi-channel deployment, ensure the text-only version remains informative and well-structured. Avoid signatures that rely solely on an image or logo, as these will render as empty on text-only channels. Related capabilities - For reusable message templates beyond signatures, see Canned Responses. - To automate agent assignment based on inbox or conversation properties, see Automation.

Last updated on Feb 25, 2026

Pre-Chat Forms

Support Portal provides a pre-chat form mechanism that captures visitor identity and context before a conversation is initiated. When enabled on a website inbox, the form requires visitors to submit structured data — such as name, email address, or organization-specific identifiers — before they can begin a live chat session. Operational objective Pre-chat forms address several operational requirements: - Contact identification — Ensure that every inbound conversation is linked to an identifiable contact record. This eliminates anonymous interactions and provides agents with context from the first message. - Data enrichment — Populate contact fields automatically with visitor-provided data, reducing manual data entry and improving record completeness. - Routing precision — Collected field values can be used as conditions in automation rules, enabling conversations to be assigned to the correct team or agent based on the information provided. See Automation. - Compliance readiness — For regulated environments, pre-chat forms ensure that required identifiers (e.g., citizen ID, account number, case reference) are collected before any interaction begins. Pre-chat forms are available exclusively for website live chat inboxes. Enabling the pre-chat form Navigate to Settings > Inboxes, then select the configuration panel for the target website inbox. Open the Pre Chat Form tab. Toggle the form to enabled. Once enabled, every visitor who initiates a conversation through this inbox will be presented with the form before the chat session starts. Configuring form fields The pre-chat form supports two categories of fields: Standard fields These correspond to core contact record properties: | Field | Description | |---|---| | Full Name | The visitor's name, mapped directly to the contact record. | | Email Address | The visitor's email, used for contact identification and follow-up notifications. | | Phone Number | The visitor's phone number, stored on the contact record. | Standard fields are available by default and cover the most common identification requirements. Custom fields Custom fields extend the form with organization-specific data points. These fields are sourced from Custom Attributes defined in your workspace. Any custom attribute created under Settings > Custom Attributes with the contact_attribute type becomes available for inclusion in the pre-chat form. To add new fields to the form, create additional custom attributes first. See Custom Attributes for configuration details. Field configuration options Each field in the pre-chat form exposes the following configuration parameters: | Parameter | Description | |---|---| | Key | The unique identifier for the field. This corresponds to the attribute key on the contact record. | | Type | The data type of the field — Text, List, Number, Date, Link, or Boolean. | | Required | When enabled, visitors cannot submit the form without providing a value for this field. | | Label | The display name shown to visitors on the chat widget. | | Placeholder | Hint text displayed inside the field before the visitor enters a value. | Administrators can perform the following actions on each field: - Enable or disable individual fields to control which data points are collected. - Reorder fields to establish a logical sequence for the visitor experience. - Modify labels and placeholders to match organizational terminology. - Toggle validation to enforce or relax required-field rules. How collected data maps to contact records When a visitor submits a pre-chat form, the platform processes the data as follows: 1. Contact matching — The system checks whether a contact record already exists with the provided email address or phone number. If a match is found, the conversation is linked to the existing contact. 2. Contact creation — If no match exists, a new contact record is created with the submitted field values. 3. Attribute population — Standard field values are written to the corresponding contact properties. Custom field values are stored as custom attributes on the contact record. This ensures that agents have full context — including any prior conversation history — from the moment a new conversation appears in their queue. Visitor experience When the pre-chat form is active, visitors see a structured form before the chat input becomes available. The form displays all enabled fields in the configured order, with required fields marked accordingly. The visitor must complete all required fields and submit the form before the conversation session begins. Once submitted, the chat interface loads and the visitor can begin typing their message. Enterprise deployment examples Pre-chat forms are particularly relevant in regulated and high-accountability environments: - Government service portals — A municipal service desk can require citizens to provide their national ID number or case reference before initiating a conversation. This ensures that every interaction is traceable and linked to the correct citizen record. - Telecom account support — A telecom operator can require the customer's account number or service contract ID as a mandatory field, enabling agents to retrieve the relevant account details immediately and reducing verification overhead during the conversation. - Financial services — A regulated institution can collect a policy number or client reference, ensuring that conversations are associated with the correct customer record from the outset and that audit requirements are met. In each scenario, the combination of required standard fields and custom attributes ensures that the organization's data collection policies are enforced consistently, without relying on agents to request this information manually during the conversation. Combining pre-chat forms with automation Pre-chat form data can serve as input for automation rules. For example: - Assign conversations to a specific team based on a custom field value (e.g., route all conversations where the "Department" field equals "Billing" to the billing support team). - Apply a label automatically based on the visitor's selection in a list-type custom field. - Trigger a notification when a high-priority identifier is detected in a submitted field. See Automation for details on configuring rules that act on conversation and contact properties.

Last updated on Feb 25, 2026

Priority

Support Portal includes a built-in priority system that allows agents and automation rules to rank conversations by urgency. Priority levels control how conversations surface in the queue and provide a consistent triage framework across teams. Operational objective Conversation priority serves two purposes in an operational environment: - Triage control — Priority determines which conversations require immediate attention and which can follow standard handling timelines. This is essential in environments with SLA obligations or regulatory response windows. - Workload signaling — Priority indicators are visible in the conversation list, giving agents and supervisors an immediate read on queue severity without opening individual conversations. Priority works alongside Labels and Automation to form a structured classification layer across the platform. Priority levels Support Portal provides four fixed priority levels: | Level | Intended use | |---|---| | Urgent | Incidents requiring immediate action, such as service outages or security-related reports. | | High | Time-sensitive matters that should be addressed ahead of the general queue, such as SLA-critical escalations. | | Medium | Standard requests that require timely but not immediate resolution. | | Low | Informational inquiries, general feedback, or tasks with flexible timelines. | These levels are intentionally fixed. Custom priority values are not supported, by design, to maintain a consistent triage vocabulary across teams and automation rules. If you need additional granularity, use Labels or custom attributes in combination with priority. Assigning priority from the conversation sidebar Open a conversation and locate the Priority field in the right-hand side panel. Select the desired level from the dropdown. Once assigned, two things happen: 1. A priority indicator appears next to the conversation in the conversation list. 2. An activity entry is recorded in the conversation timeline, logging the change and the agent who made it. Assigning priority from the context menu Right-click a conversation in the conversation list to open the context menu. Select the priority level directly without opening the conversation. This method is useful when triaging multiple conversations in sequence. Assigning priority from the command palette Open the command palette with Cmd + K (macOS) or Ctrl + K (Windows/Linux), type "Assign priority," and select from the available levels. The command palette is the fastest method when you are already working within a conversation and want to set priority without moving focus to the side panel. Priority in automation rules Priority integrates with the automation engine in two ways: - As a condition — Trigger rules when a conversation's priority matches a specific level. For example, automatically assign conversations marked as Urgent to a dedicated escalation team. - As an action — Set priority automatically based on other conversation properties. For example, assign High priority to any conversation where the subject line contains terms associated with compliance or outage reports. Priority changes made by automation rules are logged in the conversation timeline, the same as manual changes. See Automation for details on configuring rules. Priority in macros Priority can be included as a step in macros. When building or editing a macro, add the Change Priority action and select the target level. This allows agents to apply a priority assignment as part of a broader set of actions in a single step. See Macros for details on creating and managing macros. Filtering by priority Use the conversation filter controls to narrow the queue by priority level. This is particularly useful for supervisors monitoring SLA compliance or for agents working through escalation backlogs. Combined with label and team filters, priority filtering enables precise queue segmentation for operational review.

Last updated on Feb 25, 2026

Template Variables

Support Portal supports template variables — placeholders that resolve to contact, conversation, or agent data at send time. Instead of composing static messages, agents and automation rules can produce personalized content that references the recipient's name, the assigned agent, or the conversation identifier without manual lookup. Operational objective Template variables address three requirements common in enterprise and regulated communication workflows: - Personalization at scale — Outbound messages, acknowledgments, and follow-ups automatically include recipient-specific details, reducing manual effort and copy-paste errors. - Consistency across agents — Standardized message templates with embedded variables ensure that every agent delivers the same information structure, regardless of individual phrasing. - Auditability — Because variables resolve from system-held data, the resulting messages accurately reflect the current record, supporting traceability for SLA acknowledgments and ticket references. Variable syntax Template variables use double curly bracket notation: {{ object.property }} When a message containing this syntax is sent, the platform replaces each placeholder with the corresponding value from the conversation, contact, or agent record. If the value is available, it is inserted inline; if not, the fallback mechanism described below applies. Inserting a variable While composing a message or editing a canned response, type two opening curly brackets {{. The platform presents an autocomplete list of available variables. Select the required variable to insert it into the message body. Available variables The following variables are supported: | Variable | Resolves to | |---|---| | {{ conversation.id }} | The numeric identifier of the current conversation | | {{ contact.id }} | The numeric identifier of the contact | | {{ contact.name }} | The contact's full name | | {{ contact.first_name }} | The contact's first name | | {{ contact.last_name }} | The contact's last name | | {{ contact.phone_number }} | The contact's phone number | | {{ agent.name }} | The assigned agent's full name | | {{ agent.first_name }} | The assigned agent's first name | | {{ agent.last_name }} | The assigned agent's last name | | {{ agent.phone_number }} | The assigned agent's phone number | Variables in the contact.* namespace draw from the contact record associated with the conversation. Variables in the agent.* namespace draw from the agent currently assigned to the conversation. Fallback values When a variable references a field that has no stored value — for example, a contact record without a phone number — the platform can substitute a fallback string instead of leaving the placeholder blank. Define a fallback by appending the logical OR operator (||) followed by the fallback text enclosed in single quotes: {{ contact.first_name || 'there' }} In this example, if contact.first_name is empty, the message renders as "there" in its place. This prevents incomplete or awkward phrasing in outbound communications. Enterprise example A telecom operator sending SLA acknowledgment messages might use: Hello {{ contact.first_name || 'valued customer' }}, your request (conversation #{{ conversation.id }}) has been received. {{ agent.first_name || 'Our team' }} will respond within the agreed service window. This template ensures every acknowledgment includes the ticket reference and a personal salutation — even when contact data is incomplete. Undefined variable handling If a message includes a variable name that does not match any supported placeholder, the platform displays a validation warning before the message is sent. This prevents agents from inadvertently sending unresolved placeholders to contacts. Using variables in canned responses Template variables are particularly effective when combined with canned responses. A canned response containing variables acts as a reusable message template that personalizes itself for each conversation. For example, a canned response for initial SLA notification might be defined as: Hello {{ contact.name || 'there' }}, thank you for reaching out. Your conversation reference is #{{ conversation.id }}. I'm {{ agent.first_name }}, and I'll be assisting you today. When an agent selects this canned response, the platform resolves all variables against the active conversation before inserting the text. This combines the speed of pre-written responses with the accuracy of dynamic content. See Canned Responses for instructions on creating and managing reusable message templates. Variables in macros and automation Template variables are also available in macros and automation rule actions that send messages. This allows automated workflows to produce context-aware notifications — for instance, an automation rule that sends a personalized follow-up when a conversation is marked as resolved, or a macro that inserts the ticket reference into a standard closing message. See Automation for details on configuring automated actions.

Last updated on Feb 25, 2026

WhatsApp Templates

Support Portal integrates with WhatsApp Business providers to give your team access to pre-approved message templates directly within conversations. Templates are structured messages — reviewed and approved by WhatsApp — that allow agents to initiate outbound contact, send transactional notifications, and deliver standardized communications without violating platform messaging policies. This article covers template management for both WhatsApp Cloud API and Twilio WhatsApp Business inboxes. Operational objective WhatsApp enforces a session-based messaging model: once a customer conversation window expires (typically 24 hours after the last inbound message), your team can only re-engage using an approved template. Templates therefore serve a critical operational function — they are the mechanism for proactive outreach. Common enterprise use cases include: - Telecom service notifications — Planned maintenance windows, billing cycle alerts, SIM activation confirmations, or data usage threshold warnings sent to subscribers via approved utility templates. - Government appointment confirmations — Citizen-facing agencies sending appointment reminders, document readiness notices, or case status updates through compliant, pre-approved message formats. - Regulated transaction alerts — Order confirmations, shipment tracking updates, payment receipts, or policy renewal notices that require structured, auditable message delivery. Templates ensure that outbound messaging remains consistent, compliant, and traceable across your organization. Template categories WhatsApp classifies templates by purpose. The category assigned to a template affects delivery priority, cost, and compliance requirements. | Category | Purpose | Example | |---|---|---| | Utility | Transactional messages related to an existing interaction | Order confirmations, account updates, appointment reminders | | Marketing | Promotional content requiring explicit customer opt-in | Product announcements, seasonal offers, loyalty program updates | | Shipping Update | Logistics and delivery status notifications | Package dispatched, estimated delivery, delivery confirmed | | Ticket Update | Support case lifecycle notifications | Case opened, status changed, resolution summary | | Issue Resolution | Follow-up communications after a support interaction | Satisfaction check-ins, resolution confirmations | Not all categories are available through every provider. Review your provider's documentation for category-specific approval criteria and rate limits. Template content types Templates support several content formats depending on the components defined during creation. Text templates contain a message body with optional variable placeholders. Variables use positional notation — {{1}}, {{2}}, and so on — and are populated at send time with values such as customer names, reference numbers, or dates. Media templates include a header element containing an image, video, or document alongside the message body. Media files must be hosted at publicly accessible URLs and conform to WhatsApp size limits: images up to 5 MB (JPEG, PNG), videos up to 16 MB (MP4, 3GPP), and documents up to 100 MB (PDF, Office formats). Interactive templates include quick-reply buttons or call-to-action buttons. Quick replies present tappable response options to the recipient. Call-to-action buttons link to a URL or initiate a phone call, and may include dynamic parameters for personalized links (such as order tracking URLs). Supported and unsupported template features Support Portal processes the most common template types. The following features are not currently supported: - Authentication templates (OTP codes, verification flows) - List-picker and catalog templates - Carousel and multi-card templates - Location-based headers with map coordinates - Payment integration and form-based data collection templates - Flow templates with conditional branching Templates using unsupported features are excluded from the synchronized template list automatically. Creating templates at the provider level Templates are authored and submitted for approval through your WhatsApp Business provider — not within Support Portal. The creation workflow differs by provider. WhatsApp Cloud API Access the Meta Business Suite at business.facebook.com. Navigate to Account tools > Message templates and select Create template. Define the template category, language, and content structure (header, body, footer, buttons). Submit the template for WhatsApp review. Approval typically completes within 24 hours, though some templates may be processed in minutes. Twilio WhatsApp Business Access the Twilio Console at console.twilio.com. Navigate to Messaging > Content Template Builder and select Create new template. Choose the content type (text, media, quick reply, or call-to-action), configure the message structure and variables, and submit for approval. Once approved, the template receives a ContentSid identifier that links it to your Twilio account. In both cases, the approved template becomes available for synchronization into Support Portal. Synchronizing templates After a template is approved at the provider level, it must be synchronized into Support Portal before agents can use it. Automatic synchronization Templates synchronize automatically in the following situations: - When an agent opens the template selector in a WhatsApp conversation - When a new conversation is initiated on a WhatsApp inbox (Twilio provider) This means most teams do not need to manage synchronization manually — templates appear as agents interact with the platform. Manual synchronization Administrators can force a template refresh from the inbox configuration. Navigate to Settings > Inboxes, select the WhatsApp inbox, and use the Sync Templates control. This retrieves the current template list from the provider and updates the local cache. Manual synchronization is useful after bulk template changes at the provider level, or when a newly approved template needs to be available immediately. Sending a template in a conversation When a conversation's messaging window has expired — or when an agent needs to send a standardized outbound message — templates provide the mechanism. Open the conversation with a WhatsApp contact. In the message composer, select the template icon to open the template selector. The interface presents all synchronized templates for the inbox, organized by name. Use the search field to locate a specific template by name or keyword. Select a template to load its content and parameter fields. Providing template parameters If the selected template includes variable placeholders, the interface presents input fields for each parameter. Populate these fields with the relevant values — for example, a subscriber's account number, an appointment date, or a case reference ID. For media templates, provide a publicly accessible URL for the header image, video, or document. The URL must not require authentication and must serve the file over HTTPS. For templates with dynamic URL buttons, provide the URL parameter value (such as a tracking code or session identifier) that completes the button link. Review the message preview to confirm all values are correct, then select Send Template to deliver the message. The sent template appears in the conversation timeline as a structured message. Provider-specific considerations While the template workflow within Support Portal is consistent across providers, there are differences worth noting at the provider level. | Aspect | WhatsApp Cloud API | Twilio WhatsApp Business | |---|---|---| | Template creation | Meta Business Suite | Twilio Console (Content Template Builder) | | Approval authority | WhatsApp via Meta | WhatsApp via Twilio | | Template identifier | Template name + language code | ContentSid | | Campaign support | Templates can be used in WhatsApp campaigns | Campaign support for Twilio templates is planned for a future release | | Variable format | Positional: {{1}}, {{2}} | Positional: {{1}}, {{2}} (configured via Twilio Console) | | Sync trigger | Template selector opened or manual sync | Template selector opened, new conversation, or manual sync | Both providers enforce WhatsApp's messaging policies, including category-based rate limits, opt-in requirements for marketing templates, and content review for approval. Compliance and operational guidelines Template-based messaging carries compliance obligations, particularly for organizations in regulated industries. Opt-in requirements — Marketing templates require explicit customer consent before delivery. Utility and transactional templates may be sent based on an existing business relationship, but your organization's data protection policies should govern when and how outbound contact is initiated. Rate limits and quotas — WhatsApp enforces per-account sending limits that scale based on message quality and account history. Consistently high delivery failure rates or recipient complaints can reduce your account's messaging tier. Monitor template delivery metrics to maintain healthy sending thresholds. Content review — All templates undergo WhatsApp's review process before approval. Templates must serve a legitimate business purpose and comply with WhatsApp's commerce and business policies. Rejected templates can be revised and resubmitted. Media hosting — Files referenced in media templates must be served from reliable, HTTPS-enabled infrastructure. Avoid hosting media on endpoints that require authentication, rotate credentials, or impose rate limits on downloads. Troubleshooting Template does not appear after approval — Trigger a manual sync from Settings > Inboxes for the relevant WhatsApp inbox. If the template still does not appear, confirm its approval status at the provider level and verify that it uses a supported template type. Template fails to send — Confirm that all required variable fields are populated. For media templates, verify that the URL is accessible and serves the correct file format within size limits. Check whether the conversation's inbox matches the provider where the template was created. Media not rendering for recipients — The media URL may require authentication, may have expired, or may serve an unsupported format. Test the URL in an incognito browser session to confirm public accessibility. Variable mismatch errors — The number of parameter values provided must match the number of variable placeholders defined in the template. Review the template definition at the provider level to confirm the expected parameter count and sequence. For inbox configuration and channel setup, see Inboxes. For automation rules that can trigger template-based follow-ups, see Automation.

Last updated on Feb 25, 2026