People & Service module
SUPPORT / MODULESupport
Every ticket automatically carries the customer's commercial context — CRM account, sales order, invoice, asset, and project — through first-class relationship fields.
Ticket to Resolution
- 01
Intake
The ticket is created with an SLA due date calculated at intake, and carries the customer's account context automatically.
- 02
Route
A queue strategy (manual, round-robin, least-loaded, or skills-based) assigns the ticket to an agent.
- 03
Work
The agent communicates via threaded messages, with private notes for internal context, referencing the full customer-history view.
- 04
Resolve
The ticket cannot close without a resolution code entered.
What it is
The Vercentlabs Support module is a ticket-based system that tracks requests from creation through SLA-timed resolution, with full context links to the customer's account and the commercial record that triggered the issue — not a standalone helpdesk with no idea who the customer is.
Module atlas / operating conditions
Why Support becomes difficult in fragments
SLA deadlines get missed silently
A ticket sits past its due date with nobody alerted, because there's no policy-driven SLA clock actually running.
Agents lack commercial context
An agent handling a ticket can't see the customer's order history, invoices, or account status, so every ticket starts from zero.
Tickets close without documented resolution
A ticket gets marked resolved with no record of what was actually done, making the next similar issue harder to solve.
Operating outcomes
What changes when Support shares one system of record
SLA breaches are visible before they happen
Named SLA policies count business hours only and pause on pending-customer status, so the clock reflects reality.
Every ticket carries commercial context automatically
Tickets carry first-class links to the CRM account, sales order, invoice, asset, and project — aggregated into a dedicated customer-history view.
Resolution is documented, not assumed
A guarded state machine requires a resolution code before a ticket can close.
Capability architecture
The module, decomposed by operating capability.
6 capability groups organised by the way the product works, not as a flat marketing feature wall.
Ticket lifecycle
How a ticket moves from open to genuinely resolved.
- 01SLA-driven due-date calculation at intake
- 02Guarded state machine requiring a resolution code to close
Routing & assignment
Getting a ticket to the right agent.
- 01Queues with manual, round-robin, least-loaded, or skills-based assignment strategy
SLA management
Named policies that actually reflect business reality.
- 01Business-hours-only counting
- 02Pause-on-pending-customer status
Communications
Keeping the conversation and the internal notes both in context.
- 01Threaded messages
- 02Private internal notes
Knowledge base
Reusable answers, versioned and published deliberately.
- 01Versioned articles
- 02Draft-to-published lifecycle
Escalation tracking
The schema exists; automated escalation triggering is not yet live — an honest current limitation.
- 01Escalation data model (not yet automated)
Primary operating sequence
A transaction-level view of how work progresses through Support.
See it work
Ticket to Resolution
The ordered process a real Support workflow follows inside Vercentlabs.
Trigger
A customer or internal user raises a support ticket.
- Intake
The ticket is created with an SLA due date calculated at intake, and carries the customer's account context automatically.
- Route
A queue strategy (manual, round-robin, least-loaded, or skills-based) assigns the ticket to an agent.
- Work
The agent communicates via threaded messages, with private notes for internal context, referencing the full customer-history view.
- Resolve
The ticket cannot close without a resolution code entered.
Approvals
- 01N/A — Support's governance is primarily about SLA discipline and permission gating rather than approval chains.
Automated actions
- 01SLA due-date calculation at creation
- 02Business-hours-only SLA counting with pending-customer pause
Connected modules in this workflow
Outcome
A resolved ticket with a documented resolution code, full commercial context, and an SLA record that reflects real business hours.
Operational proof
Support, documented as an operating system.
Capability architecture
6 groups
Grouped by how the module is actually structured.
Primary operating sequence
Ticket to Resolution
Rendered above as an ordered process rather than a feature collage.
Connected system
5 modules
Adjacent modules are linked through the operating model on this page.
Business outcome
SLA breaches are visible before they happen
Named SLA policies count business hours only and pause on pending-customer status, so the clock reflects reality.
Ready to see Support running on your own data?
Book a DemoSystem map
Support does not operate alone.
The handoffs below are part of the operating model, not decorative cross-sells.
Tickets carry customer and contact IDs from CRM, so agents see the same account the sales team sees.
Tickets can reference the related sales order and invoice for commercial context on the issue.
A ticket can reference the specific asset involved, tracing a service issue back to actual equipment.
Tickets can reference a related quality record, connecting a customer complaint to a formal non-conformance.
Output register
What Support tells operators and managers
Open tickets, high-priority tickets, SLA breaches, escalations
Audience / Team leads, service ops managers
Rule register
What the module can run on its own
Computed automatically at ticket creation based on the applicable named SLA policy.
The SLA clock only counts business hours and pauses while a ticket is pending on the customer.
Currently a live dashboard query rather than a push notification — visible on demand, not yet alerted automatically.
Control register
How Support stays governed
Module-specific controls shown separately from the platform-wide security architecture.
Ticket actions are permissioned individually, not by one blanket support-agent role.
Support data is isolated at the row level across its full schema.
What to plan before going live.
- 01
SLA policies and business hours are configured per organization before go-live.
- 02
Queue routing strategy (manual/round-robin/least-loaded/skills-based) is chosen per team.
- 03
Resolution codes are defined to match how you actually categorize outcomes.
- 04
Support is explicitly excluded from the mobile module catalog — plan for desktop/browser access.
Buyer questions
Questions teams ask about Support
Can an agent see a customer's order history from a ticket?
Yes — tickets carry first-class relationship fields to the CRM account, sales order, invoice, asset, and project, aggregated into a dedicated customer-history view.
Can a ticket be closed without saying what was done?
No — a guarded state machine requires a resolution code before a ticket can transition to closed.
Is escalation fully automated?
Not yet — the escalation data model exists, but automated escalation triggering has not been found in the codebase. Treat escalation tracking as a schema-ready, not fully automated, capability today.