Limits and edge cases in handoff

These are deliberate design decisions with real consequences, written down here rather than left for you to discover in your queue.

One conversation produces one ticket, ever

However many times a visitor presses the control, a conversation results in one ticket. Pressing it again returns the same reference number rather than filing a second.

This holds even after the ticket is closed. We are not told by your helpdesk when a ticket closes, so we cannot distinguish "closed, and they have a new problem" from "still open, and they are pressing again". Filing a second ticket would risk duplicating an open conversation, so we do not.

If a customer comes back with something new, a new chat produces a new ticket.

Later messages are not added to an existing ticket

Once a ticket exists, the conversation continues in the widget but nothing more is appended to the ticket. The email thread in your helpdesk is the follow-up channel — your agent replies, the customer replies to that, and the conversation carries on where your team can see all of it.

Two browser tabs can produce two tickets

A conversation is per tab. A visitor with your site open twice who asks for a human in both tabs files two tickets. A daily limit per email address bounds how far this can go, but it can happen.

The identity is not verified

If your page tells us who the visitor is, we pass that through and the fields arrive pre-filled. That attribute is as editable by a determined visitor as the form it replaces, so a ticket can claim to be from someone it is not.

This is the same exposure that email-to-ticket already carries everywhere — anyone can email your helpdesk claiming to be anyone. The ticket records where the identity came from and never marks it as verified, so your agent can see which they are dealing with. If you need it to be trustworthy, signed identity is possible; ask us.

A conversation expires after an hour

Chat sessions are kept for an hour. A visitor who leaves the page open overnight and then asks for a human is told the conversation has expired and invited to start a new one, because there is no longer a transcript to pass on.

When a ticket's fate is genuinely uncertain

If a request to your helpdesk times out, we do not know whether a ticket was created. Rather than retry blindly and risk a duplicate, the request is held, and after a settling period we look your helpdesk up to see whether the ticket exists. Only if it definitively does not is one created. A lookup that itself fails is not treated as an answer.

The consequence you might notice: in this uncertain case a ticket can take a few minutes to appear. That is chosen on purpose — a ticket arriving late is a much smaller problem than two tickets arriving.