Skip to main content

Email-to-Ticket

Ticku turns inbound email into tickets. A customer mails your support address, a ticket appears in the right project, and every reply on that thread lands on the same ticket instead of creating a new one.

The Email admin page, listing every mailbox the tenant ingests from

The shape of it​

An inbox is a mailbox Ticku reads. It belongs to the tenant, not to a project — a single support@ address routinely serves several teams, so the project is a destination rather than an owner.

                        ┌─────────────────┐
  support@you.com  ───▶ │     Inbox       │
                        │  (tenant-owned) │
                        └────────┬────────┘
                                 │  routing rules decide where
                 ┌───────────────┼───────────────┐
                 ▼               ▼               ▼
           Acme Support    Contoso Support   Default project
        (recipient rule)   (domain rule)      (no rule matched)

Every inbox has a default project, and it is mandatory. Mail that matches no rule lands there. This is deliberate: an inbox that can silently drop mail is indistinguishable from one that is quietly broken, so there is always somewhere for a message to go.

:::info Support projects only An inbox's default project and every routing-rule destination must be a Support project. Ticku refuses to point email at a Dev, Consulting, or Epic project.

Rows created before this rule keep working and can still be saved as-is, but they cannot be moved to a different non-Support project — and once one lands on a Support project it can't go back. :::

What happens to a message​

  1. Fetched — either pushed to Ticku by Microsoft Graph or pulled by the poller, depending on the inbox's connection mode.
  2. Filtered — no-reply senders and bounce/delivery reports are dropped.
  3. Threaded or created — if the message replies to a known thread it becomes a comment on that ticket; otherwise it's a new ticket.
  4. Routed — new tickets go to the project chosen by the routing rules.
  5. Enriched — CC'd addresses and @mentions in the body become assignees and followers.
  6. Marked — the source message is marked read, moved, deleted, or left alone, per the inbox's after-process action.

Both transports run the same ingestion pipeline. Only fetching and marking differ, so routing, threading, mention parsing, and de-duplication cannot drift between them.

Threading​

Ticku stamps its outbound mail with a Message-ID that embeds the ticket id, then reads In-Reply-To and References on the way back in. A reply is matched to its ticket by:

  1. The ticket id parsed out of one of our own Message-IDs, or
  2. The referenced ids matched against stored thread roots and previously processed messages — which catches a customer replying to their own earlier email.

Anything that resolves to neither is a genuinely new conversation.

:::note Replies never re-route Routing applies to new tickets only. A reply threads onto its existing ticket and stays in whatever project that ticket already lives in, even if the rules have changed since. :::

De-duplication​

The RFC Message-ID is the dedup key. If the same message is fetched twice — two poll cycles overlapping, a webhook redelivery — the second ingestion is recorded as DUPLICATE and does nothing. Messages arriving without a Message-ID cannot be deduped.

Outbound replies​

Ticku can reply on the ticket's email thread. Which events send mail is configured per inbox and can be overridden per routing rule:

EventDefaultNotes
Acknowledgement on ticket creationOnThe first "we got it" reply
Every commentOffOff by design — comments have no internal/public flag, so on mails internal discussion to the customer verbatim
Status changeOnCovers assignment too, since assigning auto-transitions OPEN → ASSIGNED

An agent can opt a single comment in regardless of the flag by writing @creator in it.

Where to go next​