Customer Service Ticketing, SLA & Call Management

Customer Service Capabilities & Processing Boundaries

• Service ticket lifecycle Create service tickets, assign priorities and owners, manage lifecycle states and callbacks, and keep threaded comments.
• SLA & escalation signals Use ticket priorities, lifecycle timestamps, and high or urgent case alerts as the workspace's SLA-tracking and escalation signals.
• Knowledge base Author categorized Markdown guidance, mark it eligible for future or provider AI use, set its future AI priority, and review a recorded usage count that does not prove live retrieval.
• Call-provider connections Click-to-call opens Quo's web dialer, and outbound SMS uses the Quo API. Call logs and provider recordings depend on configured call-event webhooks; inbound SMS needs a separate webhook that the current guided setup does not expose. The generic custom-phone path imports call records only when a provider can POST OLT’s expected callData envelope to the configured webhook. OLT does not automatically normalize vendor-specific payloads or offer a live connection test for this path. It does not provide generic outbound SMS or click-to-call.
• OLT AI and stored voice-agent boundary OLT AI uses local Ollama by default. Only the default local Ollama configuration has zero data egress to an external model provider and no metered provider cost. If an operator explicitly configures an external OLT AI or agent endpoint, that provider processes prompts and relevant ERP context externally, and its use may incur provider charges. Stored Customer Service knowledge-base entries are not currently retrieved for ticket or call answers, and click-to-call does not load them. Customer Service stores Retell AI, Bland AI, Vapi, and custom as selectable provider values on voice-agent configuration records; it does not currently connect to or run agents through those providers. Greeting, prompt, phone, duration, status, and ticket, stock, pricing, callback, and transfer settings are stored fields only and do not execute calls or ERP actions.

Quo buyer guide

How Quo works with OLT

Quo (formerly OpenPhone) connects provider-managed calling and SMS with OLT's Customer Service and Sales CRM records. Setup verifies the provider account and separates browser dialer handoff, call events, outbound SMS, and inbound SMS events so buyers can evaluate the complete workflow.

Buyer value

Representatives can start from customer context in OLT, continue the live call in Quo, and retain supported call and message activity in the CRM when the required provider events are configured.

Prerequisites

• The Customer Service / Support Tickets module must be enabled for the organization.
• Setup needs a Quo account, a Quo API key, and a member with module-administrator access to Customer Service.

Setup boundaries

• Configuring only the displayed call webhook does not enable inbound SMS or delivery-status updates; those events need the separate SMS-event webhook that is not exposed by the current guided setup.
• Rotating the OLT signing secret invalidates the value used by both Quo webhook configurations until the administrator updates them.
• Live call audio remains with Quo; OLT does not carry the call audio and stores only the supported call-log, recording-link, message, status, and CRM activity records it receives.
• Recording links and transcription fields are not guaranteed. What appears in OLT depends on the connection and provider configuration and on the events or fields Quo supplies.

Verified setup and handoff

1. Step 1

   Module-admin setup

   A Customer Service / Support Tickets module administrator creates the company-wide connection in Customer Service → Phone Integrations and saves the Quo API key.

2. Step 2

   API-key and phone-number test

   Test Connection sends the saved API key to Quo's phone-number endpoint. A successful test activates the connection and caches the phone numbers Quo returns; saving a key without testing does not verify it.

3. Step 3

   Quo web-dialer handoff

   CRM click-to-call first records an outbound call attempt in OLT, then opens Quo's web dialer with the customer number. The representative completes the call in Quo; OLT does not place the call through a calling API or carry the call audio.

4. Step 4

   Signed call and recording events

   In Quo, add the call webhook URL displayed by OLT, use the generated signing secret, and subscribe to call.completed and call.recording.completed. Signed events update the OLT call log and attach a provider recording when Quo supplies one.

5. Step 5

   Outbound CRM SMS

   Sales CRM sends outbound SMS through the Quo API for an active connection and stores the sent message and CRM activity in OLT.

6. Step 6

   Separate SMS event webhook

   Inbound messages and outbound delivery statuses require a second signed Quo webhook for message events. The current guided phone setup displays only the call-event webhook and does not expose this separate SMS webhook setup.

Quo and Custom Webhook Compared

OLT's two phone-integration paths have different setup requirements and capabilities. Choose the connection whose documented workflow matches your provider.

Quo (formerly OpenPhone)

• The Customer Service / Support Tickets module must be enabled for the organization.
• Setup needs a Quo account, a Quo API key, and a member with module-administrator access to Customer Service.
• A Customer Service / Support Tickets module administrator creates the company-wide connection in Customer Service → Phone Integrations and saves the Quo API key.
• Test Connection sends the saved API key to Quo's phone-number endpoint. A successful test activates the connection and caches the phone numbers Quo returns; saving a key without testing does not verify it.
• CRM click-to-call first records an outbound call attempt in OLT, then opens Quo's web dialer with the customer number. The representative completes the call in Quo; OLT does not place the call through a calling API or carry the call audio.
• In Quo, add the call webhook URL displayed by OLT, use the generated signing secret, and subscribe to call.completed and call.recording.completed. Signed events update the OLT call log and attach a provider recording when Quo supplies one.
• Sales CRM sends outbound SMS through the Quo API for an active connection and stores the sent message and CRM activity in OLT.
• Inbound messages and outbound delivery statuses require a second signed Quo webhook for message events. The current guided phone setup displays only the call-event webhook and does not expose this separate SMS webhook setup.
• Configuring only the displayed call webhook does not enable inbound SMS or delivery-status updates; those events need the separate SMS-event webhook that is not exposed by the current guided setup.
• Rotating the OLT signing secret invalidates the value used by both Quo webhook configurations until the administrator updates them.
• Live call audio remains with Quo; OLT does not carry the call audio and stores only the supported call-log, recording-link, message, status, and CRM activity records it receives.
• Recording links and transcription fields are not guaranteed. What appears in OLT depends on the connection and provider configuration and on the events or fields Quo supplies.

Custom call webhook

Without the custom webhook, calls from another phone system are not ingested through the documented callData route.

• The generic custom-phone path imports call records only when a provider can POST OLT’s expected callData envelope to the configured webhook. OLT does not automatically normalize vendor-specific payloads or offer a live connection test for this path. It does not provide generic outbound SMS or click-to-call.
• The custom webhook cannot send SMS through OLT or create provider-backed Sales CRM SMS timelines.
• The external phone system processes calls outside OLT and must send each callData payload to OLT.

Customer Service FAQ

Which voice-agent provider values can I store?

Customer Service stores Retell AI, Bland AI, Vapi, and custom as selectable provider values on voice-agent configuration records; it does not currently connect to or run agents through those providers. Greeting, prompt, phone, duration, status, and ticket, stock, pricing, callback, and transfer settings are stored fields only and do not execute calls or ERP actions.

What do the stored voice-agent action toggles do?

They save preferences for ticket creation, stock checks, pricing checks, callback scheduling, and human transfer. OLT does not currently consume these settings to execute calls or ERP actions, so selecting a toggle does not activate that capability.

What does the Customer Service knowledge base store?

It stores categorized Markdown guidance together with publication state, future or provider AI eligibility, priority from 1 to 10, and a recorded usage count. Customer Service does not currently retrieve these entries for ticket or call answers, click-to-call does not load them, and the recorded count does not show that an entry improved or even appeared in a live answer.

Where does the AI run, and does my data leave my server?

OLT AI uses local Ollama by default. Only the default local Ollama configuration has zero data egress to an external model provider and no metered provider cost. If an operator explicitly configures an external OLT AI or agent endpoint, that provider processes prompts and relevant ERP context externally, and its use may incur provider charges. Stored Customer Service knowledge-base entries are not currently retrieved for ticket or call answers, and click-to-call does not load them. Customer Service stores Retell AI, Bland AI, Vapi, and custom as selectable provider values on voice-agent configuration records; it does not currently connect to or run agents through those providers. Greeting, prompt, phone, duration, status, and ticket, stock, pricing, callback, and transfer settings are stored fields only and do not execute calls or ERP actions.

What phone providers can I connect, and what does setup support?

Click-to-call opens Quo's web dialer, and outbound SMS uses the Quo API. Call logs and provider recordings depend on configured call-event webhooks; inbound SMS needs a separate webhook that the current guided setup does not expose. The generic custom-phone path imports call records only when a provider can POST OLT’s expected callData envelope to the configured webhook. OLT does not automatically normalize vendor-specific payloads or offer a live connection test for this path. It does not provide generic outbound SMS or click-to-call.

When do call recordings and transcripts appear?

Recordings and transcripts are not universal. The Call Center shows them only when the connected provider supplies those fields through its configured webhook payload; otherwise the call record remains available without them.

Do stored voice-agent settings create service tickets?

No. Retell AI, Bland AI, and Vapi appear only as provider values on voice-agent configuration records, and OLT does not currently connect those records or create tickets from them. Service tickets use their separate lifecycle with priorities, assignments, SLA signals, callbacks, and threaded comments.