How to build a support history to CRM sync

What matters here

• Summarise, don't copy. The account team needs the state of support for the account, not every ticket.
• Match on an id, not a name. Name matching fails on exactly the largest customers, which have several entities and several spellings.
• Show the trend. Five open tickets is normal for one customer and a crisis for another.
• Escalations go to the account owner as they happen, not in a weekly report.
• Link back to the help desk. The CRM shows the summary; the detail lives where support works.

Who this is for

You run customer success operations, support operations or revenue operations. Support works in the help desk, the account team works in the CRM, and neither can see what the other knows about the same customer.

How it works in practice

What happens between a customer opening a ticket and the account team knowing about it.

1. 1

   A ticket is opened or changes

   New, escalated, solved or reopened. Each change is a reason to refresh the account's summary.

2. 2

   The ticket is tied to a CRM account

   Through the help desk organisation's stored CRM account id. A ticket with no match goes to a review list, not to a guess.

3. 3

   The summary is rebuilt for that account

   Open tickets, the highest priority open, the oldest open, escalations in the last 30 days, and the count against the same period last quarter.

4. 4

   The summary is written to the account

   A handful of read-only fields and a link to the account's tickets in the help desk.

5. 5

   Escalations reach the owner

   An urgent ticket or an escalation on an account with a renewal close goes straight to the account owner and the customer success manager.

6. 6

   A nightly check catches anything missed

   Every account's summary is rebuilt from the help desk once a day, so a missed update corrects itself by morning.

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

   Set up, then decide what the account team sees

   Choosing what not to send is most of this build.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Zendesk and Salesforce,
   or whatever we run in those seats.
   
   Before anything is built, help me choose the summary. I want at most
   six fields on the account, and each has to pass one test: would an
   account manager do something differently if it changed.
   
   My starting set: open tickets, the highest priority open ticket, days
   the oldest open ticket has been open, escalations in the last 30 days,
   tickets this quarter against the same period last quarter, and a link
   to the account's tickets in the help desk.
   
   Tell me which of those our help desk data can support reliably.

2. 2

   Tie every ticket to the right account

   A summary on the wrong account is worse than none.

   Headless skills build-workflow

   Copy

   Use build-workflow. Store the Salesforce account id on each Zendesk
   organisation, and match tickets to accounts through that id only.
   
   Never match on company name or email domain alone. Large customers
   have several entities, subsidiaries and spellings, and a name match
   puts their tickets on the wrong account.
   
   For organisations with no account id, try the email domain against
   account websites once, and put every suggested match on a review list
   for support operations to confirm. Nothing is written to the account
   until a person confirms the match.
   
   Handle parent and child accounts: roll the summary up to the parent
   for the relationship view, and keep the child figures, because that is
   where the problem usually is.

3. 3

   Build the summary, not a copy of the tickets

   The CRM shows the state of support. The help desk keeps the detail.

   Copy

   Rebuild the account's summary whenever one of its tickets is created,
   escalated, solved or reopened. Rebuild it from the help desk each time,
   rather than adding and subtracting, so a missed update can't leave a
   count wrong for good.
   
   Write the summary to read-only fields on the account, with the time it
   was last updated. Set field level security so nobody edits them in the
   CRM: a hand-corrected ticket count disagrees with the help desk and
   gets believed.
   
   Do not create a CRM record per ticket. Add the link to the account's
   tickets in Zendesk instead.

4. 4

   Send escalations to the account owner

   The account team should hear about a serious problem from support before the customer tells them.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then alert the account owner and the customer
   success manager directly when:
   
     An urgent ticket is opened on an account above a value we set
     A ticket is escalated on an account with a renewal inside 90 days
     Open tickets for an account double against last quarter
   
   Put the account, the ticket subject, its priority and a link to the
   ticket in the message. Send it once per ticket, even if the ticket is
   updated several times, so the owner is not messaged on every reply.
   
   Never alert on volume alone for accounts that always run high. A
   customer with a large support team opens a lot of tickets, and alerts
   on that get muted.

   The renewal case is the one that pays for the build: an escalation in the last quarter before a renewal is the conversation the account manager most needs to have early.

5. 5

   Keep it honest about gaps and freshness

   A stale summary is worse than an empty one, because someone acts on it.

   Copy

   Every night, rebuild the summary for every account from the help desk
   and compare it with what is on the account. Fix any difference and
   record it, so a missed update is visible.
   
   Alert if the sync has not completed within its expected window.
   
   Report weekly: the share of tickets matched to an account, the number
   waiting on the review list, and escalations sent against escalations
   the account team acted on.

6. 6

   Prove it works, then hand the thresholds to customer success

   Which tickets are worth an interruption is a judgement about your customers.

   Copy

   Run the per-step checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so customer success
   operations can change the alert thresholds, the account value cut-off
   and the renewal window in the visual canvas. They change as the
   business does, and they belong to the team that acts on them.

What it connects to

Tickets are read in one place, summarised, and only the summary reaches the CRM.

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