A board, hierarchy, merges, approvals, macros, time and the numbers behind all of it. Put the whole support team on it and the bill does not move.
Six statuses, four priorities, three levels of hierarchy, and no per-agent fee.
A figure you cannot interrogate is a decoration. Every metric here lists the tickets behind it.
An AI suggester was a headline claim on this page and was never built. The rest is smaller, and a team that picks this tool expecting any of it will find out in week one.
The solutions panel suggests articles by matching the words you have typed against article titles and bodies. That is a substring search. There is no model, no embedding, no summarisation and no draft-a-reply. An earlier version of this page called it an AI suggester, and it never was one.
Articles can be read in the portal and, if you turn it on, in a public help center anyone can search. What is missing is any measure of them: no view counts and no usefulness ratings, so you cannot yet tell which articles are earning their keep.
The weekly timesheet is on screen and billable time can be pushed onto an invoice, but there is no CSV of raw time entries. The analytics page does export to CSV; the timesheet does not.
What happens to a single ticket, arrival, triage and the thread, is the desk itself.
How one ticket gets answeredLay the queue out as columns, either by status or by the stages of a ticket pipeline, on the web or the phone. Drag a card on the web, or move it from the card's menu on the phone. Tickets merged into another one stay off the board.
A first-response target and a resolution target, both defaulted from priority, both counted against your business-hours calendar. Move a ticket to Pending and the clock stops until it comes back.
Group related incidents under a parent problem. The ticket page shows the whole tree on the web and the phone, with link and detach beside it. The depth limit is three and it is enforced, along with a self-parent guard and a cycle guard, so nobody can build a tree that hangs the page that renders it.
Roll duplicates into one primary ticket with the email threads intact, from the ticket page on the web or the phone. The merge records which rows it moved, which is what lets unmerge put them back rather than approximate them. A merged ticket's status cannot be changed until it is unmerged, so it cannot quietly reopen while its history lives on the other ticket. An admin, or whoever created both tickets, can do it.
An approval rule matches on priority, ticket type and team, and gates the close transition until someone signs off. The request itself is a record: pending, then approved, rejected or cancelled.
A macro applies a written reply, a status change and an assignment in one action. Org macros are admin-owned and shared; personal macros are yours, and nobody else can see or edit them.
Attach a knowledge-base article to a ticket and it stays attached. Articles move through draft, reviewed and approved before publication, and a typeahead offers matches while an agent writes a reply.
A timer per agent plus manual entries, each one marked billable or not, at a rate snapshotted when it is logged so a later rate change cannot rewrite history. Billable time becomes invoice lines.
Select rows in the list and change status, reassign or delete them together. Each ticket in the batch is checked on its own, so a bulk action cannot become a way around the per-ticket rules.
Median, plus a daily series and the count that breached
Against a per-priority target you set, with how many were met, missed, and the breach rate
Mean and median, broken down by priority
Open and urgent counts, day by day
Handled, response time, breaches and satisfaction, per person
First response, next response and resolution, overall and per priority
The average rating, how many there are, and the spread from one to five
Every figure opens the tickets behind it, or exports
The approval rules, the merge and unmerge endpoints and the analytics module are all in the open repository.
No. Ticket management is part of BottleCRM core, sharing the same accounts, contacts, custom fields and permissions. One install, one login, one database.
For a small team, often yes: statuses, a board, SLAs with business hours, hierarchy, merges and unmerges, approvals, macros, a knowledge base with an optional public help center, replies emailed as threaded mail, time tracking, and analytics with satisfaction scores, with no per-agent fee. Two things to weigh first. Inbound email arrives through Amazon SES only, with no IMAP, Gmail or Microsoft 365 connection. And there is no live chat channel of any kind.
Mail to your support address opens a ticket, and replies thread onto the existing one rather than opening another. Thread identifiers survive a merge, so consolidating duplicates does not fragment the conversation. Spam, bounces and auto-replies are dropped, and every message is recorded even when it is dropped.
In the structural sense, yes. Tickets are typed as question, incident or problem, and incidents nest under a parent problem up to three levels, with the depth, cycles and self-parenting all guarded server-side. Closing a parent can cascade to its children, defaulting to your org setting and overridable on the individual close. What it does not have is a change-management or CMDB layer.
Yes. An approval rule matches on priority, ticket type and team, and blocks the close until an approver acts. The request is a record with four states, pending, approved, rejected and cancelled, and the person who asked for approval cannot be the one who grants it.
More than this page used to claim. An earlier version said approvals and analytics were web-only; both ship on the phone, along with the approvals inbox, the per-ticket approval panel, the macro picker and the close-with-children dialog, on top of the queue, ticket detail, comments and the create and edit flows. The ticket board is on the phone too, one column per page with a move menu on each card.
Every agent, every ticket, on your own database. Host it yourself, or let MicroPyramid run it.
