Support that already knows the customer

A standalone helpdesk can only ever hold half of the conversation. It knows the email address, the subject line and the thread — and nothing about whether the person writing has spent $50 or $50,000 with you, what they last bought, or whether your delivery team is already three days late on their project. So the agent asks the customer questions the business could have answered itself, and the reply that goes out is polite and uninformed.

Because Stillpoint's CRM, WooCommerce order data, projects and tickets live in one database on your own server, the agent opens a ticket and the context is simply already there. On one screen, without navigating away: the CRM contact and their company, the account owner, lifetime spend, order count and average order value, the specific linked order with its line items, SKUs, quantities, payment and shipping method and any refund, open and won deals, active projects and open tasks, every previous ticket, and the customer's own satisfaction score.

That is the difference between a WordPress ticket system and a support platform. It is not a feature that can be bolted on later with an integration, because the integration would still be reading someone else's database over an API, one request at a time, with none of it available to reports.

Email is where most WordPress helpdesk plugins quietly fall apart. Replies arrive as new tickets, one message gets delivered twice, an out-of-office opens a ticket nobody asked for, and an auto-reply loop fills a queue overnight. Email-to-ticket in Stillpoint was built assuming all of that will happen, because it will.

You can run several support mailboxes, and each one carries its own team, brand, SLA policy, signature, auto-reply and ticket number prefix. Connection options are deliberately broad: IMAP works immediately with no setup beyond credentials, and TLS verification is always on and cannot be switched off; Gmail and Microsoft 365 connect over OAuth; secure forwarding to an opaque address works when you would rather not hand over mailbox access at all; and inbound webhooks are supported for SendGrid, Mailgun and Postmark.

Threading is matched in a deliberate order of trust. A signed reply token first, then the RFC headers — Message-ID, In-Reply-To and References — then the provider's own thread identifier, and only then a ticket number found in the subject line. Even that last route requires the sender to already be a participant on the ticket, so a stranger who quotes your ticket number gets their own ticket rather than being dropped into somebody else's conversation.

Duplicate delivery is impossible by construction rather than by careful coding: deduplication is enforced by a database constraint, not a code path that could be bypassed. Quoted history is trimmed for readability but the original message is always retained. Inline images work. Automatic replies and out-of-office messages are detected per RFC 3834 and filed as internal notes instead of opening tickets. Bounces are shown on the ticket, so an agent never assumes a reply landed when it did not. And four independent brakes prevent mail loops.

SLA management is where support promises meet arithmetic, and most tools get the arithmetic wrong in the customer's favour or yours, depending on the day. Stillpoint tracks first response, next response and resolution targets, against either business hours or calendar hours, using timezone-aware schedules with holiday calendars — as many schedules as you need, because a UK team and a South African team do not share a working week.

Clocks pause while you are legitimately waiting on the customer, and the clock history is append-only. That single design choice is why the reporting can be trusted: SLA figures are rebuilt from what actually happened, segment by segment, rather than inferred from a ticket's current status. A ticket that sat paused for three days still reports honestly a month later.

Escalation ladders fire at percentages of the target rather than only at the breach, so a supervisor hears about a ticket at 75% while there is still time to act. And every deadline can be explained in plain language, segment by segment: created Monday 15:00, two hours of working time left that day, Tuesday was a public holiday, resumed Wednesday 08:00, due Wednesday 10:00. If a schedule has no working hours defined at all, Stillpoint withholds the deadline and says so rather than inventing one.

Routing runs as ordered rules, so the first rule that matches wins and the behaviour is predictable. Assignment strategies include round robin, least-loaded, spare-capacity, required skill, and — uniquely — the CRM account owner, so a key account's own contact answers their ticket rather than whoever happened to be free.

Capacity is weighted by priority rather than counted as rows, which is the difference between a fair queue and a busy-looking one: five low-priority questions are not the same load as two urgent escalations. Conditions can also read commerce data — order value, customer lifetime spend, RFM segment, product SKU — which is only possible because the store lives in the same database as the tickets.

Every routing decision is written to the ticket timeline, including the negative ones: "left unassigned, nobody had spare capacity" is recorded explicitly. An assignment is never mysterious, and neither is a non-assignment.

Macros perform several steps at once — set a status, apply tags, assign, draft a reply — but they never send a reply on their own. A drafted reply lands in the composer for a human to read before it goes out, because the fastest way to damage a customer relationship is an automated message that was almost right. Saved replies use merge tokens that are safe by design.

Collision detection means you see "Sarah is replying to this ticket" before you spend ten minutes writing the same answer, and a stale save is refused rather than silently overwriting a colleague's work. Tickets can be merged and split, and given typed relationships including parent and child. Followers can watch a ticket without owning it, and email CC participants are handled properly: a copied address becomes a participant on the conversation, never a CRM user.

Bulk actions re-check permissions per ticket rather than once for the batch, so a bulk operation can never become a quiet privilege escalation.

The customer portal signs people in with passwordless magic links, and the tokens behind them are hashed, expiring and single-use. No ticket is reachable by editing a number in a URL, which is a failure mode WordPress support plugins have shipped more than once. Intake forms support conditional fields, and field visibility is re-evaluated on the server rather than only hidden in the browser.

The knowledge base is versioned, with a draft, review and published workflow, view and helpfulness analytics, and a knowledge-gap report built from searches that returned nothing — which is the single most useful list a support team can have, because it is written by your customers.

CSAT surveys go out after a delay, respect a per-customer cooldown so nobody is surveyed repeatedly, and carry a small-sample caveat: a 5.0 from two responses is never presented as a rating. Multi-brand support means one install can serve several support identities, each with its own address, portal look, signature and knowledge base.

When one outage generates hundreds of tickets, the problem stops being individual replies and becomes consistency. Link the affected tickets to a single incident, and every agent has the same status text to quote, so three customers do not get three different explanations of the same event.

One update can then be sent to everyone attached to the incident. That send is capped per run and requires explicit confirmation, on purpose: mass customer email deserves friction, and a support tool that makes it effortless is a support tool that will eventually embarrass you.

The Service Desk registers into the same reporting engine as the sales and commerce modules. It is not a second reporting system with its own filters and its own definition of a month — tickets, ticket messages, SLA targets and satisfaction responses simply become new reportable objects alongside deals, contacts and orders. Nineteen documented service metrics and fourteen report templates ship with it.

Then there are the two reports a standalone helpdesk structurally cannot produce. Tickets per 100 orders, which tells you whether support load is growing faster than the business. And support load per product SKU — tickets per 100 units sold, per SKU, with the top three issue categories for each. That is how you find the product whose sizing description is quietly costing you money, and it is only possible because the orders and the tickets are in one database.

Alongside those: agent and team scorecards read next to workload rather than in isolation, backlog by age, reopen rate, and one-touch resolution — which in Stillpoint requires that the ticket was never reopened, because a single reply that did not actually work is not a resolution. There are also operational diagnostics for email threading health and for replies that never reached the customer.

A bug report that dies in a helpdesk is a customer who is never told. From a ticket an agent can raise a work item on a board or project, and the link is bidirectional — engineering sees where the report came from, and the agent is notified when the work is finished, so nobody is left waiting on a task that was completed last Thursday.

Service events also feed the existing cross-module automation engine, so a support event can create a project, open a follow-up, notify an owner or fire a webhook, with the same idempotency guarantees as every other trigger in Stillpoint.

There are seven service roles, from viewer through to service admin, and field-level control on top of them. That combination matters in practice: an agent can be given the order context they need to answer a question while lifetime spend and refund history stay hidden from them.

Record scoping is applied in four places rather than only in the interface — the queue query itself, every report and export, attachment downloads, and direct URL access. A restriction that only exists in the UI is not a restriction.

Inbound email HTML is sanitised on arrival against an allow-list. Remote images are blocked by default, so a tracking pixel cannot tell a sender the exact moment your agent opened their message. Attachments are validated by magic bytes as well as file extension — a file called invoice.pdf that begins with a Windows executable header is rejected — and are only ever served as downloads, never rendered inline. Mailbox credentials are encrypted at rest and never shown back, and portal tokens are stored hashed.

Every list of capabilities is more useful with its boundaries drawn. Here is exactly what is not in the Service Desk today, stated plainly so you can decide before you buy rather than after.