Revolutionary Ticketing Documentation

Revolutionary Ticketing turns WordPress into a real customer support help desk. Every request, whether it arrives by email or through the customer portal, becomes a ticket: a custom post type stored in your database, with a status, a priority, an assigned agent, a threaded conversation and an SLA timer.

Agents work from a filterable inbox in the admin and reply directly from each ticket, with the customer's account, orders and past tickets visible in a context sidebar. Customers can email you like they always have, or log in to a clean front-end portal placed anywhere with the [support_tickets] shortcode.

Tip: Tickets are a normal custom post type. That means they're covered by your existing WordPress backups, exports and user roles, no separate data store to manage or migrate later.

Revolutionary Ticketing installs like any standard WordPress plugin. Use the bundled .zip archive or install it directly from the Revolutionary Plugins hub.

Upload the plugin. In your WordPress admin, go to Plugins -> Add New -> Upload Plugin and choose revolutionary-ticketing.zip. Click Install Now.
Activate. Once installed, click Activate. A new Tickets menu appears in the admin sidebar.
Run the setup wizard. On first activation the wizard registers the default statuses and priorities, sets your business hours, and creates a portal page containing the [support_tickets] shortcode.
Verify your license. Paste your license key under Tickets -> Settings -> License to unlock email piping, SLA timers, canned replies and priority support.

Heads up: Email piping reads a real mailbox over IMAP. Have your support inbox host, username, password (or app password) and the IMAP port ready before you enable it under Tickets -> Settings -> Email.

Let's open a ticket, assign it, and reply, so you can see the full loop an agent works through. The whole thing takes about two minutes.

Create a ticket. Go to Tickets -> Add New. Enter a subject, the customer's name and email, then write the opening message. Pick a starting status and priority.
Assign an agent. In the ticket sidebar, choose an agent from the Assigned to dropdown. Any user with the revtickets_agent capability appears here.
Reply or add a note. Use the reply box at the bottom. A public reply emails the customer; an internal note stays visible to agents only.
Set status & priority. Switch the status to Pending while you wait on the customer, or Solved when it's done. The SLA timer reacts to these changes.
Hand it to the portal. Add the [support_tickets] shortcode to any page so customers can see this ticket, follow its status, and reply from the front end.

That's the core loop: open, assign, reply, resolve. Everything else in this guide automates parts of it.

Every ticket carries one status (where it is in your workflow) and one priority (how urgent it is). Both are fully editable: rename them, recolor them, and add your own under Tickets -> Settings -> Workflow. The defaults cover most teams out of the box.

Field	Default values	What it controls
Status	Open, Pending, On hold, Solved, Closed	Which inbox view a ticket appears in, and whether its SLA clock is running
Priority	Low, Normal, High, Urgent	The SLA targets that apply and the sort order in the inbox
Color	Per status & priority	The label color shown on inbox rows and in the conversation header
SLA clock	Runs on Open / paused on Pending	Whether time counts toward a breach while a ticket sits in that status

Status changes are the heartbeat of the plugin: moving a ticket to Pending typically pauses its SLA clock, and marking it Solved stops the timers entirely. Each transition fires the revtickets_status_changed hook, so you can wire up your own automation.

An agent is any WordPress user granted the revtickets_agent capability. Agents see the ticket inbox, can reply to customers, write internal notes, and change status and priority. Assignment routes a ticket to one agent so nothing falls between the cracks.

Manual assignment: pick an agent from the ticket sidebar or reassign inline from the inbox row.
Round robin: distribute new tickets evenly across the agent pool automatically.
Rules: auto-assign by priority, source mailbox, or a keyword in the subject.
Workload counts: the inbox sidebar shows how many open tickets each agent holds, so you balance by eye.

Assignment respects roles: only users with the agent capability can be assigned, and you can scope which agents see which mailboxes if you run separate support queues for different products.

Canned replies are saved answers you reuse for common questions. Build a library under Tickets -> Canned Replies, then insert one into any reply with a single click and edit it before sending, so it stays personal.

Replies support smart tags that resolve to the current ticket and customer, such as {customer:first_name}, {ticket:id}, {ticket:subject}, {agent:name}, and {ticket:url}. So a single saved reply greets each customer by name without any copy-paste.

Hi {customer:first_name},

Thanks for reaching out about {ticket:subject}.
To dig in, could you tell me which browser and device
you are on? I will get ticket {ticket:id} sorted quickly.

Best,
{agent:name}

Tip: Give each canned reply a short slug and type /slug in the reply box to insert it without opening the picker.

Email piping connects a real mailbox to the help desk so customers never need an account. New emails become tickets, and replies thread back onto the right ticket automatically by matching a hidden token in the subject and the sender address.

Configure it under Tickets -> Settings -> Email. You can connect by IMAP (the plugin polls your inbox on a schedule) or by forwarding (your mail host forwards to a secret pipe address). Each connected mailbox can map to a default status, priority and agent queue.

Setting	Example	Notes
Method	IMAP	IMAP polling or forwarding pipe; pick one per mailbox
Host / port	imap.example.com : 993	Use SSL/TLS; an app password is recommended over your login
Poll interval	Every 5 minutes	Runs on WP-Cron; lower it for busier inboxes
Default queue	Open - Normal - Tier 1	Status, priority and agent group applied to new tickets

Security note: Store mailbox credentials as app passwords, not your primary email login, and never reuse the forwarding pipe address publicly. Attachments on incoming mail are scanned and stored privately, served only through a signed, expiring URL on the ticket.

An SLA (service level agreement) timer is a promise about how quickly you'll respond and resolve. Define targets per priority under Tickets -> Settings -> SLA: a first response deadline and a resolution deadline. Each ticket then shows a live countdown that turns red as it approaches a breach.

Per-priority targets: Urgent might be 30 minutes to first reply, Low a full business day.
Business-hours aware: the clock pauses outside your configured hours and on weekends, so deadlines stay realistic.
Status-aware: moving a ticket to Pending pauses the clock because you're waiting on the customer.
Escalation: when a ticket is at risk, reassign it, bump its priority, or notify a manager automatically.

SLA outcomes are recorded on every ticket, so the dashboard can show your within-SLA percentage over any date range, useful evidence when a client asks how responsive your support really is.

The portal is a front-end page where logged-in customers open new tickets, track the status of existing ones, and read and reply to your agents, all in your own site's theme. Place it anywhere with the shortcode and the plugin handles the rest.

Customers only ever see their own tickets. The portal shows each ticket's current status and priority, the full conversation (public replies only, never your internal notes), and a reply box. New submissions from the portal land in the inbox exactly like a piped email would.

Tip: Put the portal behind your normal login or a membership wall. Because tickets are scoped to the logged-in user, a customer can only ever load their own conversations, even by guessing a ticket ID.

Render the customer portal anywhere using the shortcode. With no attributes it shows the full portal: a ticket list plus a new-ticket form for the logged-in user.

// Full portal: list + new-ticket form
[support_tickets]

// List only, hide the new-ticket form, default to Open
[support_tickets show_form="false" status="open"]

In the block editor, search for "Support Tickets", insert the block, and configure the same options from the inspector sidebar. You can also render the portal from a PHP template using the revtickets_render_portal() helper function.

Developers can extend nearly every part of the ticket lifecycle with WordPress actions and filters. Use the revtickets_status_changed action to run custom logic whenever a ticket moves between statuses, here we post an alert to Slack and stamp the ticket when it is solved:

add_action( 'revtickets_status_changed', function( $ticket_id, $old, $new ) {
    if ( 'solved' !== $new ) {
        return;
    }
    update_post_meta( $ticket_id, '_resolved_by', get_current_user_id() );
    my_slack_notify( sprintf( 'Ticket #%d resolved', $ticket_id ) );
}, 10, 3 );

Use the revtickets_assign_agent filter to override automatic assignment. Other commonly used hooks include revtickets_after_reply_sent, revtickets_sla_breached, revtickets_ticket_created, and revtickets_portal_query (filter which tickets a customer sees).

Most issues trace back to email piping or cron. Work through these first:

Piped emails not becoming tickets: confirm the IMAP host, port and credentials, and check that WP-Cron is firing. A long poll interval or a host that blocks cron can delay new tickets.
Replies create new tickets instead of threading: the matching token was stripped. Make sure outgoing notifications send through an authenticated SMTP provider and that the subject token is not being rewritten by a mail filter.
SLA timers look wrong: almost always business hours. Set your timezone and working hours under Settings before trusting the countdowns.
Customer can't see their tickets in the portal: the portal scopes tickets to the logged-in user by email. Confirm the account email matches the ticket's customer email exactly.
Notifications not arriving: the ticket is still saved, so check Tickets -> All Tickets. If tickets exist but no email goes out, install an SMTP plugin and authenticate your sending domain.

Tip: Enable Tickets -> Settings -> Logging to record every piped message, reply and SLA event.

No. You can create unlimited tickets and add unlimited agents. Tickets live in your own WordPress database, so the only practical limit is your hosting storage.

Not with email piping. Customers email your support address and a ticket is created, with replies threading back to them automatically. The portal is an optional extra for logged-in users who want to track tickets on your site.

Yes. The ticket view shows a context sidebar with the customer's account, recent orders and past tickets. It works alongside Revolutionary eCommerce and standard WooCommerce so agents answer with full history.

Yes. Tickets are a custom post type in your database, and the plugin integrates with WordPress native data export and erase tools. You can also set retention windows to auto-delete old, closed tickets.

No. The agent inbox, statuses, priorities, assignment, internal notes and the customer portal are fully functional in Free. Pro unlocks email piping, SLA timers, canned replies, auto-assignment rules and priority support.

DOCUMENTATION

Getting started

Statuses & priorities

Agents & assignment

Email piping

SLA timers

Developers

Introduction

Installation

Your first ticket

Statuses & priorities

Agents & assignment

Canned replies

Email piping

SLA timers

Customer portal

Shortcode & block

Hooks & filters

Troubleshooting

FAQ

Frequently asked questions

Was this helpful?