Commitments go unmeasured
Response and resolution targets exist in a contract but not in the tool, so nobody finds out they were missed until a customer says so.
Paycon Ticketing Platform
Your support desk. Your brand. Our platform underneath.
A multi-tenant support operations platform for organisations that run a service desk for their own customers. Each operator gets a branded desk with its own domain, policies and data boundary — on one platform that Paycon builds, upgrades and operates.
The problem it solves
Service desks are easy to start and hard to run.
Branding stops at a logo
Serving customers under your own brand usually means a separate instance per client, or a shared instance that leaks whose it is.
Nothing is accountable
Who changed the priority, who reassigned it, who saw the attachment — unanswerable once edits overwrite history.
The platform treats all three as first-class concerns: SLA clocks and escalation are part of the ticket model, operator branding is a tenant configuration rather than a deployment, and the audit record is append-only.
Modules
What is in the platform.
Each module is a deployable service with its own responsibility. Operators enable what they need; the contract between modules does not change per tenant.
Ticketing core
Intake, queues, assignment, priority, custom fields per tenant, linked tickets, internal notes separated from customer-visible replies.
SLA and escalation
Business-calendar clocks for response and resolution, pause on customer-wait, and tiered escalation that notifies the next level when a target is at risk.
Notifications
Email, SMS, WhatsApp and in-app messages from per-tenant templates, delivered by a worker that retries and records what was sent.
Knowledge base
Articles with review state and helpfulness voting, surfaced at ticket creation so the obvious questions deflect before they become tickets.
Search
Tickets and articles indexed continuously from the database, with tenant scoping applied at query time, not filtered afterwards.
Webhooks and API
A REST API published as an OpenAPI contract, and signed outbound webhooks with retry and dead-letter handling for downstream systems.
Attachment handling
Uploads to object storage with virus scanning before a file is ever served, and signed, expiring download links.
Audit and SIEM
Append-only audit tables for every state change, forwarded to your security information and event management system on a schedule.
Brand publishing
Operator brand tokens — colours, logo, sender identity, domain — published to the edge so each tenant's desk loads as its own product.
White-label
One platform, many operators.
An operator is a tenant with its own brand, domain, policy set and users. Adding one is a configuration change, not a fork — which is the only way a white-label product stays maintainable past the third customer.
- Own domain A verified custom hostname per operator, with its own certificate.
- Own identity Logo, colour tokens, email sender and templates per operator.
- Own policy SLA calendars, escalation tiers, field catalogue and permissions set per operator.
- Own data Every query is tenant-scoped at the repository layer; there is no global read path.
| Layer | Enforcement |
|---|---|
| Request | Tenant resolved from hostname and token, then pinned for the request |
| Authorisation | Permission matrix evaluated per tenant and role |
| Data | Repository base class applies the tenant predicate to every query |
| Search | Tenant filter applied in the index query |
| Files | Object keys namespaced per tenant; links signed and expiring |
| Audit | Tenant recorded on every append-only entry |
Security posture
Built so an auditor can follow it.
The platform is designed for operators who will be asked how their support data is handled. These are engineering controls built into the product — not a certification claim.
Access control
Role-based permissions evaluated per tenant, with a declared permission matrix rather than ad-hoc checks scattered through handlers.
Secrets and keys
Credentials held in a managed secret store, encryption keys managed by the cloud KMS, and no secrets in images or repositories.
Untrusted input
Attachments scanned before they are retrievable; request payloads validated against schemas at the boundary.
Traceability
Append-only audit records for state changes, forwarded off-box so they survive the system they describe.
Data residency
Deployed in AWS ap-south-1 by default, so Indian operators keep support data in-country.
Recoverability
Versioned schema migrations, automated database backups and environment promotion through code rather than console clicks.
Architecture
A modular monolith with workers around it.
One API service owns the transactional core. Everything with its own failure mode and retry story — notifications, webhooks, SLA timers, indexing, scanning, audit forwarding — runs as a separate worker behind a queue.
| Service | Responsibility | Shape |
|---|---|---|
| api-svc | Tickets, tenants, users, authorisation, OpenAPI surface | HTTP service |
| web-spa | Agent and customer interfaces, themed per operator | Browser app |
| notification-svc | Email, SMS, WhatsApp and in-app delivery with retries | Queue worker |
| webhook-svc | Outbound webhook delivery, signing, retry, dead-letter | Queue worker |
| sla-scheduler | SLA clocks and tiered escalation | Scheduled worker |
| search-indexer | Database changes to the search index | Queue worker |
| attachment-scanner | Virus scanning before files become retrievable | Queue worker |
| audit-forwarder | Append-only audit tables to the operator's SIEM | Scheduled worker |
| brand-publisher | Operator brand tokens to the edge | Queue worker |
Status: the platform is under active development by Paycon. Availability for a new operator is discussed against a current delivery plan rather than a public roadmap.
Operators
Want to run your desk on it?
Tell us how many customers you support, what you have promised them, and what you run today. We will tell you honestly whether the platform fits, and when.