Straight answers about Protocol.

Protocol is a customer service workspace for conversations, tickets, customer context, knowledge, automation, reporting, quality, and integrations. It is designed to reduce the amount of context teams have to reconstruct as an issue moves from first contact to resolution.

Protocol is designed for customer support, customer success, service operations, and related teams that need shared customer context and coordinated workflows. It can support a focused team as well as larger service organizations that need clearer permissions, routing, reporting, and administration.

A conversation is the direct customer interaction, while a ticket is structured work created when the issue needs owners, dependencies, tasks, dates, or a service target. Protocol keeps the two connected so the operational work does not lose the original customer context.

Yes. Protocol Intelligence helps with tasks such as research, summaries, classification, drafting, recommendations, and approved workflow actions using the context available to the workspace. Teams retain control over permissions, review points, and handoff rules for customer-impacting work.

Yes. Protocol connects with communication, CRM, commerce, engineering, data, and automation systems while allowing those tools to remain systems of record where appropriate. APIs and webhooks support custom integration patterns when a packaged connection is not the right fit.

Protocol's knowledge model supports both internal service documentation and external help-center content. Teams can organize articles and control how knowledge is used so agents and customers can reach the right guidance for their situation.

Automation is built around explicit triggers, conditions, actions, permissions, and review points rather than hidden background behavior. Teams can start with simple routing or follow-up and expand into more complex service workflows as they learn where automation is reliable and useful.

Managers can review service performance signals such as response, resolution, SLA risk, backlog, recurring issues, and quality criteria defined for the team. The purpose is to connect a metric or score back to the conversations and workflows that explain it so improvements can be specific.

No. Protocol is intended to coordinate the service workflow and bring useful context together, not to duplicate every connected system. CRM, billing, commerce, product analytics, and engineering tools can continue to serve as authoritative systems for the information they own.

Protocol currently starts with a guided sales and onboarding process. The first step is to map your service workflows, channels, systems, migration needs, controls, and rollout goals so the initial workspace reflects how your team actually works.

Protocol brings service conversations from connected channels such as email, chat, messaging, phone, social, and API sources into one working queue. Agents can review the conversation, customer context, ownership, and recent service history before they reply.

Teams can organize routing around signals such as intent, language, priority, customer value, team ownership, and current workload. This lets the queue reflect how your service organization actually operates instead of forcing every conversation through one static assignment rule.

Yes. The Inbox is designed around shared ownership with assignments, internal notes, mentions, views, and collision awareness so agents can coordinate without duplicating replies. Customer-facing messages remain separate from the internal context the team uses to resolve the issue.

Use a ticket when a customer issue needs structured work such as owners, dependencies, due dates, tasks, or an SLA beyond the immediate conversation. The original conversation stays connected so the team does not have to copy customer context into a separate work tracker.

Protocol supports structured views such as lists, boards, tables, and timelines for ticket work. Teams can choose the view that fits the workflow while keeping ownership, related conversations, dependencies, and service targets attached to the same record.

Tickets make escalation work explicit by giving the issue clear ownership, dates, dependencies, and SLA context. That structure helps support, operations, and specialist teams see what is blocked, what needs attention next, and which customer conversation is affected.

Protocol Intelligence works with the live conversation, customer history, approved company knowledge, service policy, and connected operational context available to the workspace. Keeping those sources together helps recommendations stay grounded in the same information the service team uses.

No. Protocol helps service teams with research, classification, summaries, drafting, recommendations, and approved actions while keeping permissions and handoff points visible. Teams can decide where review is required and where a configured workflow may proceed automatically.

Knowledge-assisted responses surface relevant source material so agents can review the basis for an answer before sending it. This is especially useful when service policy, product documentation, or customer-specific context affects the correct response.

Automation can be used for repeatable service work such as routing, prioritization, follow-up, notifications, SLA actions, and multi-step workflow coordination. Workflows are built from explicit triggers, conditions, actions, and approval points so teams can understand what will happen and why.

Yes. A workflow can include AI-assisted work such as classification, summarization, or preparation when that step is appropriate for the process. Important actions can still be limited by permissions or routed through a human review point before business state is changed.

Start with high-volume, predictable workflows where the desired outcome and exception path are easy to define, such as routing or follow-up. Once those rules are stable, teams can expand into more complex service operations without creating a large set of brittle automations at once.

A customer record can bring together service history, account information, notes, open work, billing events, product activity, and other connected context your team uses during support. The exact record depends on the systems your organization connects and the data it chooses to make available in Protocol.

Not necessarily. Protocol can keep existing systems of record in place while bringing the customer information that matters for service into the agent workflow. This reduces context switching without requiring every underlying business system to be rebuilt inside the support platform.

Agents can make better decisions when they can see the customer's recent conversations, open issues, account state, and relevant activity before responding. That context helps reduce repeated questions and makes handoffs between support, success, and specialist teams easier to follow.

Yes. Protocol is designed for internal service knowledge as well as content intended for a customer help center, with publishing and access choices based on how the article should be used. Keeping both types of knowledge close to the service workflow makes it easier to maintain consistent answers.

Repeated customer questions and service conversations can reveal topics that are missing, unclear, or outdated in the current documentation. Teams can use those patterns to decide what should be written or revised instead of relying only on occasional manual audits.

Protocol can assist with drafting and suggested updates using the service context available to the workspace. A team can review the proposed content before publishing so the final article still reflects approved product information and service policy.

Useful measures include response and resolution time, SLA attainment, backlog, reopens, escalations, customer satisfaction, and the amount of work handled through automation or AI-assisted workflows. The right set depends on the service model, so teams should focus on metrics that explain customer outcomes rather than collecting every available number.

That is a core goal of connected reporting. Instead of stopping at a dashboard number, teams can move toward the conversations, queues, issues, customers, and workflows that contributed to a change and decide what operational action is appropriate.

No. Leaders may use broader trend and capacity views, while managers and frontline teams often need narrower views of queues, SLA risk, recurring issues, and workflow performance. Keeping those views in the same service system helps teams discuss performance using shared operational context.

Protocol is designed around configurable scorecards that can evaluate service dimensions such as accuracy, clarity, empathy, process adherence, and resolution quality. Teams can use consistent criteria across more conversations and then direct manager attention toward examples that need coaching or deeper review.

No. Automated review can make coverage broader and surface conversations that deserve attention, but managers still set the standard and interpret the result in context. Coaching, policy changes, and performance decisions should remain grounded in the team's operating expectations and human judgment.

Service teams often need different criteria for different queues, products, or customer situations, so the quality model should reflect the work being reviewed. Protocol's quality approach is designed around configurable criteria and weighting rather than one universal score for every conversation.

Protocol connects communication, CRM, commerce, engineering, data, and automation tools, along with custom integrations through APIs and webhooks. The purpose is to bring relevant service context and actions into the customer workflow while existing systems can remain authoritative for their own data.

They do not need to. A good integration should expose the customer or operational context agents actually need and preserve the appropriate system of record for the rest. This keeps the workspace useful without turning it into an unnecessary duplicate of every connected application.

Protocol provides a developer story around APIs, webhooks, events, and custom applications for workflows that are not covered by an existing integration. Teams should define the data, permissions, and failure behavior of a custom integration before using it in customer-facing operations.

Protocol currently uses a guided sales and onboarding process rather than a self-service checkout. That process is used to understand your service model, migration needs, integrations, controls, and rollout scope before a workspace is configured.

The recommended plan depends on the size and structure of your service operation, the capabilities you need, implementation requirements, and the controls required for rollout. Commercial terms are tailored with the sales team after that scope is understood.

Yes. A team can begin with a focused service workflow and expand into additional channels, automation, reporting, intelligence, or specialized teams as the operating model becomes clearer. The onboarding plan should define the first use case and the conditions for expanding it.

Migration and integration requirements are part of the guided rollout conversation described on the pricing page. The exact work depends on your existing service systems, the information that needs to move, and which connected tools should remain systems of record.