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.
Both were headline claims on this page. One is built and unreachable, the other was never built at all, and a team that picks this tool expecting either will find out in week one.
This was the first card on this page and it described drag-and-drop kanban with custom pipelines and stages. All of that is built in the backend and neither the web app nor the phone can open any of it. Tickets have three views: the queue, the approvals list and the analytics page. If a board is how your team works, this is the gap to weigh.
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.
Customers who sign in to the portal can search your published articles and are offered matching ones while they raise a request. What does not exist is an anonymous help centre: nothing is readable without a sign-in, nothing is crawlable, and there are no article URLs you can link from a public page. There are also no view counts or usefulness ratings yet, so you cannot 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 answeredA 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 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. The merge records which rows it moved, which is what makes the unmerge endpoint able to put them back rather than approximate them.
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
Mean and median, broken down by priority
Open and urgent counts, day by day
Handled, response time, breaches and satisfaction, per person
First response and resolution, overall and per priority
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 team that works from a queue, mostly yes: statuses, SLAs with business hours, hierarchy, merges and unmerges, approvals, macros, an internal knowledge base, time tracking and analytics, with no per-agent fee. Two things to weigh first. There is no board, so if your team runs on a kanban this will feel wrong from day one. And the help centre is sign-in only: customers who log in can search articles and are shown matching ones as they type a request, but there is nothing anonymous or crawlable, so it deflects your existing customers rather than search traffic.
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 gap runs the other way: the board does not exist on either client.
Every agent, every ticket, on your own database. Host it yourself, or let MicroPyramid run it.
