Mail arrives, becomes a ticket, and already knows which account it came from and what they bought. Two SLA clocks that understand your working week, and a library built from answers you have already given.
Unlimited agents, no per-seat fee. MIT licensed, self-host it anywhere.
The customer's mail, your replies, the internal notes and every field change, in the order they happened.
A ticket's job is not only to get closed. It is to leave the team able to answer it faster next time.
Mail to your support address becomes a ticket, and so does a web form on your own site. Replies thread onto the ticket they belong to instead of starting a new one, and the sender is matched to a contact you already have.
A routing rule picks the owner: round-robin through a group, whoever is least busy, or a named person. Priority sets both SLA clocks the moment the ticket is created.
One timeline carries the customer emails, your replies, the internal notes and the attachments. A public reply goes to the customer as an email in the same thread. An internal note stays internal: it does not reach the customer and it does not reopen a closed ticket.
Promote the answer into the solutions library, where it goes through draft, reviewed and approved before anyone relies on it. Then the customer gets asked how it went.
The desk is real and the clocks are real. What is missing is a live channel, and any mail provider other than Amazon SES on the way in.
A customer can read the thread, reply to it and raise a new request. They cannot attach a file to any of that, so a screenshot still has to come by email, where it does attach to the ticket properly. This is the one thing people expect from the portal that is not there yet.
Mail reaches the CRM through an Amazon SES receipt rule. There is no IMAP polling and no Gmail or Microsoft 365 connection, so a support address on either of those has to forward to an SES address first. Outbound replies need SES inbound too if you want the customer's answer to come back by email; without it the email asks them to reply in the portal.
A web form can open a ticket, but nothing live drops onto your website. There is no chat, no messenger bubble and no WhatsApp or social channel.
Webhooks can tell another system when a ticket is created, updated or gets a public reply. An escalation is not one of those events, and there is no PagerDuty or Opsgenie integration, so escalation re-assigns and notifies inside the app.
A ticket has one priority: low, normal, high or urgent. There is no second severity axis and no matrix crossing the two. Both SLA targets come from the priority alone, and you can override either on an individual ticket.
This is the desk: what happens to one ticket. Running the whole queue is a separate story.
Boards, merges, approvals and the numbersEvery ticket carries a first-response target and a resolution target, both set from its priority. Urgent starts at one hour to first reply and four to resolve; low starts at a day and three days.
SLA deadlines are counted in business hours against a calendar your org defines, so a ticket that arrives at 6pm on Friday is not already late by Monday. Close the office for a public holiday and the clocks stop.
Move a ticket to Pending and the elapsed time stops accumulating against the SLA. Move it back and it resumes. Time spent waiting on someone outside your team is not time you were slow.
The inbound pipeline decides three things: drop it, thread it onto an existing ticket, or open a new one. Every message is recorded, including the dropped ones, so nobody has to guess what happened to an email.
A public reply is emailed to the contacts on the ticket with the reply text in it, threaded the way a mail client expects, and tagged with the ticket number in the subject. When they answer from their inbox, the answer comes back onto the same ticket.
Build a web form in Settings, set it to create tickets, and paste it onto your support page. The sender is matched to a contact by email, or one is created, and the ticket is routed and put on the SLA clock exactly as an emailed one would be.
A customer signs in to your support portal with a six digit code you email them, and sees the requests they are named on: the status, the thread, and a box to reply in. They can raise a new one there too. Nothing they see needs an account in your CRM.
The portal is a narrower view of the ticket, not the same page with fields hidden. Internal notes are never loaded for it. Assignment, SLA counters, tags and your colleagues names are not in the response at all, and a reply from your side is attributed to Support rather than to whoever typed it.
Solutions are written from real resolutions and move through draft, reviewed and approved before publication. Each one links back to the tickets it came from, and search covers the title and the body.
Turn it on in Settings and your approved, published articles appear at /help-center/your-name on your own CRM domain, with no sign-in. Readers can search it, each article links related ones, and a sitemap lists every article so search engines can find them.
Half an hour after a ticket closes, the contact gets a one-to-five rating link. If the ticket has been reopened by then the survey is skipped, because asking how it went while it is still going is worse than not asking.
The SLA rules, the inbound pipeline and the escalation task are all in the open repository.
Yes. They go to your portal, type their email address, and we send them a six digit code that signs them in for a day. From there they see the requests they are named on, read the thread, reply, and raise a new one. Two limits worth knowing: they cannot attach a file, and they see only their own requests, so a colleague at the same company does not automatically get to read a ticket they were not put on. Email still works exactly as before for anyone who prefers it, and replies thread back onto the ticket automatically.
Both clocks are counted in business hours against a calendar your organisation defines, including public holidays, so a ticket raised at 6pm on Friday is not eight hours late by Saturday morning. Set no calendar and the clocks run 24/7. Separately, moving a ticket to Pending pauses the clock entirely, so waiting on the customer does not count against you.
A background task scans open tickets every five minutes. When one crosses its configured threshold, the escalation rule attached to it fires: it can re-assign to another person or team and notify inside the app. It stays inside the CRM: an escalation is not a webhook event and there is no paging integration, so nothing wakes anyone up in another tool on its own.
Yes, if you want them to. The public help center is off by default; an admin turns it on and picks the address it lives at. From then on every article that is both approved and published is readable by anyone at that address, searchable there, and listed in a sitemap for search engines. Drafts and unapproved articles never appear. Signed-in customers still get the same articles inside the portal, and the new-request form still suggests them as they type.
Not directly. Inbound mail is received through Amazon SES, and that is the only provider built. A Gmail or Microsoft 365 address can forward to your SES address, and replies still go out from the CRM as threaded email that the customer can answer.
Honest answer: it is a substring match on the title and the body, not a ranked full-text index, and an earlier version of this page named PostgreSQL full-text search that is not in use. It works well on a library of a few hundred articles and will feel blunt on several thousand. The suggester that offers articles while an agent types a reply runs on the same match.
Put the whole support team on it without counting seats, on your own database. Host it yourself, or let MicroPyramid run it.
