AgentticCRM
Book a demo
Back to the product map

Support and requests

Turn every client request into visible ownership and a traceable answer

Clients can open and follow requests from their portal while the team triages status, priority and ownership in its own workspace. Public replies, internal notes, files and linked work remain explicit instead of collapsing into one ambiguous thread.

Operating outcome

Know who owns the request, what the client can see and what must happen next.

The implemented ticket flow joins client intake, staff triage, a permission-aware conversation and operational follow-through. It gives people a shared record without claiming that every communication channel is one omnichannel inbox.

Operating outcomes

What this product area helps make visible

These outcomes connect the implemented capability to a practical operating change. They are review paths, not guaranteed performance claims.

Ownership and next actions people can see

Pipeline actions, project assignments, tasks, ticket ownership, reminders, and status make responsibility inspectable across commercial, delivery, and support work.

See the supporting outcome

Client collaboration with a deliberate visibility boundary

The client portal exposes client-scoped proposals, invoices, projects, tickets, account details, and notifications while the team retains its internal workspace.

See the supporting outcome

Reusable knowledge with provenance and human control

Authored documents, indexed knowledge, cited answers, permissions, audit history, and recovery controls keep reusable information separate from unreviewed automation.

See the supporting outcome

Human journey

From incoming request to a client-visible resolution

Receive the request in the right surface, place it with a responsible person, resolve it with the right visibility and leave the outcome in the same record.

  1. Receive the request

    Let an authorized client open a ticket in the portal or let a permitted staff member create it with the relevant client context.

  2. Place visible ownership

    Set status and priority, assign the working party and use response and due-date signals to decide what needs attention first.

  3. Resolve with the right visibility

    Reply publicly when the client should know, write an internal note when the team needs private context and attach the files that belong to either message.

  4. Leave the outcome in context

    Link the project, service, tasks, reminders or reusable response that helped resolve the request, then keep the final status visible to the people allowed to follow it.

A support record that distinguishes ownership from visibility

The product implements separate staff and client surfaces, explicit ticket states, shared working parties, public and internal conversation modes, attachments and linked resolution work. Optional analysis stays inside the staff record.

Staff and client ticket intake

Create a ticket from the staff workspace with client, description, priority, assignees and files, or let a portal user open and follow a request from the client side.

What is implemented
The staff ticket list implements creation and attachment upload; the portal ticket list implements client-side creation, search, status filtering and follow-up links.
Availability boundary
Staff creation requires the tickets feature and tickets:create. Client intake additionally depends on the portal feature, an authorized portal user and that client's own ticket scope.

Status, priority, response clock and working party

Triage the queue by workflow state, urgency, client and assignee, then place one or more staff members on the request and keep due and first-response signals attached.

What is implemented
The ticket list implements status counts, statistics, persisted filters, quick status, priority and assignment actions; the ticket schema stores assignees, first response, last response and due date.
Availability boundary
Visibility is limited to global viewers, assigned staff and the unassigned triage queue. Editing status, priority, dates or assignees requires the corresponding ticket mutation scope.

Public replies, internal notes and protected files

Keep the client conversation and the team's private working context in one ticket without exposing internal notes or internal attachments through the portal.

What is implemented
The detail screens share a ticket thread and attachment flow, while the API records visibility per comment, notifies clients only for public replies and excludes staff-only fields from the portal DTO.
Availability boundary
Staff replies require tickets:edit and stored attachments must pass the ticket storage contract. Portal users can reply only inside tickets visible to their own client account.

Linked work, reminders, tags and reusable responses

Attach the request to its project or service, turn follow-up into tasks, schedule reminders, label the record and reuse approved response text when the situation repeats.

What is implemented
The ticket detail and API implement project and service links, related tickets, task conversion, reminders and tags; the canned-response routes implement permission-gated create, update and delete actions.
Availability boundary
Linked project, task and service actions depend on those modules and the person's permissions. Managing or deleting canned responses has its own ticket permissions.

Optional ticket analysis recorded as an internal note

Ask the Assistant to read the ticket, its images, approved knowledge and comparable past resolutions, then place the grounded analysis inside the staff conversation rather than sending it to the client.

What is implemented
The ticket detail exposes analysis and image-reading actions; the API requires ticket edit scope, checks the assistant feature and writes the result with AI authorship and internal visibility into the audited thread.
Availability boundary
Analysis requires the assistant feature, a usable configured provider and tickets:edit. It is an optional staff aid, not an automatic client response or resolution decision.

Connected paths

Review the client-facing portal, the approved knowledge that can support a response or the complete Product map.

Inspect the client portal boundary See the focused client surface for opening requests, reading public replies and following only records shared with that client. Connect the answer to approved knowledge Explore how documents, indexed sources, cited answers, access controls and recovery support reliable operational decisions. Return to the complete Product map Place support beside the client record, delivery, revenue and the controls that keep the operation reliable.

Read before choosing

Support is connected without pretending every channel or decision is automatic

Ticketing, portal access and optional assistance have separate features and permissions. The page states those seams because they determine what each person can actually do.

  1. Ticketing is not an omnichannel contact center

    The product has ticket, inbox and alert surfaces, but this page does not claim that every email, social message, phone call or alert is automatically normalized into one universal support queue.

  2. Client access is a separate entitlement

    The tickets feature governs the staff workflow. Client-side ticket access additionally requires the portal feature and available portal-user capacity in the selected plan.

  3. Assistance never replaces ticket ownership

    Tickets, replies and resolution tracking work without AI. When analysis is enabled, a person invokes it, the result stays internal and the accountable team still decides and communicates the answer.

Next decision

Choose what you need to verify next

You do not need to read the whole site. Continue with the fit, adoption, price, or control question that matters to this decision.

  1. Run a structured CRM evaluation

    Name the broken handoff, map the complete workflow, and ask each provider for evidence before choosing.

    Use the evaluation guide

  2. Confirm plan fit and current price

    Review published plans, billing periods, included capabilities, limits, and configuration conditions.

    Review pricing

  3. Review control and risk questions

    Inspect isolation, permissions, approvals, audit evidence, continuity, and deletion boundaries.

    Open the trust center

Bring one request that keeps losing an owner.

We will trace how it enters, who can act, what the client sees and which operational record carries the resolution.

Book a capability demo See the product map