How to build support intake from every channel

What matters here

• Every channel a customer can reach you on is a support channel, whether or not the help desk knows about it. Shared Slack channels are the usual gap.
• Match the sender to an account before anything else. An unmatched ticket routes blind.
• A second message about the same problem should join the open ticket. Three tickets for one problem means three agents and three different answers.
• Reply on the channel the customer used. Moving them to email to suit the tool is the first bad experience.
• Count the tickets that arrive unmatched. It tells you how good your contact data is.

Who this is for

You run support operations. Email and the help desk widget create tickets, but chat, phone and the shared Slack channels with your biggest customers are handled by whoever sees them first.

How it works in practice

What has to happen between a customer reaching out on any channel and a ticket being ready to route.

1. 1

   The message arrives on whatever channel the customer chose

   Email, the help desk widget, live chat, a web form, a phone call or a shared Slack or Teams channel.

2. 2

   The sender is matched to a contact and an account

   By email address first, then by email domain, then by the Slack workspace or phone number on the account.

3. 3

   It joins an open ticket or opens a new one

   Same requester, same account, an open ticket on the same subject in the last few days: it joins. Otherwise it is new.

4. 4

   The ticket records where it came from

   The channel, the original message and a link back to it, so the agent can reply where the customer is.

5. 5

   Unmatched senders are flagged, not dropped

   A ticket from an unknown address still gets answered, and a person links it to the right account.

6. 6

   Replies go back on the original channel

   An agent's reply in the help desk posts to the Slack thread, the chat or the email the customer used.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   First, list every channel and how it arrives today

   The channels nobody counted are where tickets go missing.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Zendesk, Intercom, Slack,
   Aircall and Salesforce, or whatever we run in those seats. Before you
   plan anything, tell me which of them are already authenticated in the
   workspace.
   
   List every way a customer can reach support today: support email
   addresses, the help desk widget, live chat, web forms, the phone line,
   and every shared Slack or Teams channel with a customer. For each, tell
   me whether it creates a ticket now, and if not, who sees it.
   
   From Zendesk I need the Ticket and User models, including the channel
   field and external ids. From Salesforce I need Contact and Account with
   email domains, support tier and the Slack workspace or channel id if we
   store one.

2. 2

   Match every sender to an account

   A ticket with no account carries no tier, no history and no owner.

   Headless skills build-workflow

   Copy

   Use build-workflow. On every inbound message, match the sender in this
   order:
   
     1. Exact email address on a Contact
     2. Email domain on an Account, skipping free mail domains
     3. Slack workspace or channel id stored on the Account
     4. Phone number on a Contact or Account
   
   Write the matched Contact and Account to the ticket, with the support
   tier and the account owner. Record which rule matched, because a domain
   match is weaker than an exact address.
   
   If nothing matches, still create the ticket, tag it unmatched and post
   it to the support ops channel so a person can link it. Never drop or
   hold a message because the sender is unknown.

3. 3

   Join follow-ups to the open ticket

   Three tickets for one problem means three agents and three answers.

   Headless skills tray-patterns

   Copy

   Use tray-patterns. Before creating a ticket, look for an open one from
   the same requester on the same account, created in the last five days.
   
   If the new message replies to that ticket's thread, or clearly refers to
   the same problem, add it as a comment on the open ticket and tell the
   assignee. If it is a different problem, open a new ticket.
   
   Where it is unclear, open a new ticket and suggest the merge to the
   agent rather than merging it yourself. Two tickets that should be one
   cost a merge; one ticket that should be two hides a problem.
   
   Messages can arrive twice from the same channel when a webhook retries.
   Check the message id before creating anything, so a retry never opens a
   second ticket.

4. 4

   Reply where the customer asked

   Moving a customer to email to suit the tool is the first bad experience.

   Copy

   When an agent replies on a ticket that started in Slack, post the reply
   to the original thread. Do the same for chat. Replies from the customer
   in that thread come back as comments on the ticket.
   
   Internal notes never leave the help desk. Check the comment is public
   before posting anything to a channel the customer can see.
   
   Report weekly: tickets by channel, tickets that arrived unmatched and
   how long they took to link, and follow-ups joined versus suggested
   merges.

   The public-comment check is the one to test hardest. An internal note posted to a customer's Slack channel is the incident this workflow can cause.

5. 5

   Validate, then hand the channel list to support ops

   Because shared channels open every time a big deal closes.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so support operations can add
   a new shared channel, a new support address or a new matching rule in
   the visual canvas without asking engineering.

What it connects to

The channels bring the message, the CRM says who sent it, and the help desk holds the ticket.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Further reading

Background on the same subject, for the case rather than the build.

• Solving the challenges of modern customer support with automation

Related guides