How to build integration request tracking

What matters here

• Collect requests where customers already make them. A separate form only catches the customers who find the form.
• Match every request to one named app. Twelve spellings of one tool are one request.
• Count an account once, however many people at it ask. Otherwise the noisiest customer sets the roadmap.
• Weigh by revenue and by lost deals, side by side. They point at different integrations, and both matter.
• Tell the customer when it ships. A request that disappears into a list teaches customers to stop asking.

Who this is for

You run product or partnerships at a software company. Integration requests arrive in deal notes, support tickets and feature-request boards, and the roadmap is decided in a meeting from memory.

How it works in practice

What happens between a customer asking for an integration and that ask showing up on the roadmap.

1. 1

   A request is captured where it was made

   A lost-deal reason in the CRM, a ticket tag in support, a note in the feedback tool or a mention on a recorded call.

2. 2

   It is matched to one named app

   Against your list of apps, so "MS Dynamics", "Dynamics CRM" and "D365" all count toward the same integration.

3. 3

   It is tied to an account

   So five people at one customer asking is one account asking, with five votes of evidence behind it.

4. 4

   The revenue behind it is added

   Annual value of the customers asking, and the value of deals lost or stalled where the integration was the reason given.

5. 5

   Product sees a ranked list

   Updated daily, with the evidence one click away instead of in somebody's inbox.

6. 6

   Customers hear when it ships

   Everyone who asked gets told, through their account owner or directly.

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

   Find where requests already live

   Before building, see what you can read.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Salesforce, Zendesk,
   Productboard, Gong and Slack, or whatever we run in those seats. Before
   you plan anything, tell me which of them are already authenticated in
   the workspace.
   
   I want every place a customer asks for an integration today:
   
     Closed-lost and stalled opportunities with a reason or note naming
     an app
     Support tickets tagged as an integration request, or mentioning one
     Notes in the feedback tool linked to an integration
     Call transcripts where a prospect asks "do you integrate with"
   
   Show me ten real examples from each before deciding how to read them.

2. 2

   Match every request to one app

   Twelve spellings of one tool are one request.

   Headless skills build-workflow tray-gotchas

   Copy

   Use build-workflow and tray-gotchas. Keep a table of apps: the name we
   use, its common alternatives and old names, and whether we already have
   an integration for it.
   
   For each new request, match the text to one app in the table. Where
   the match is unclear, or names an app not in the table, send it to a
   person in Slack with the original text, and add their answer to the
   table so the same text matches next time.
   
   Never guess between two apps. A request filed against the wrong app is
   worse than one waiting for a person.

3. 3

   Count accounts, not mentions

   So the noisiest customer doesn't set the roadmap.

   Copy

   Tie every request to an account in Salesforce, by the opportunity, the
   ticket's organisation, or the contact's email domain.
   
   Keep every individual request as evidence, but count each account
   once per app. Add to each app's row:
   
     Customers asking, and their total annual value
     Open and lost deals where it was the reason given, and their value
     The most recent request date
     Whether any asking customer is up for renewal in the next two
     quarters
   
   Rank by whichever of those product chooses, and show both values side
   by side. They point at different integrations.

4. 4

   Publish the list and close the loop

   A request that vanishes teaches customers to stop asking.

   Copy

   Write the ranked list to Productboard as one record per app, with the
   linked accounts and evidence, and refresh it daily.
   
   When an integration ships, find every account that asked for it and
   tell each account owner in Slack, with the list of contacts who asked.
   Mark the request closed on the ticket, the opportunity and the
   feedback note.

5. 5

   Check it, then hand the app list to product

   Because the matching table is product's call.

   Copy

   Run the per-step checks and the whole-workflow audit before this
   touches production. Run it once over the last year of requests and
   compare the top ten with what product believes the top ten are.
   
   Then open the same workflow in Tray Build so product operations can
   edit the app table and the ranking in the visual canvas.

   The first run over a year of history is usually the moment the roadmap changes. Plan for that conversation.

What it connects to

Requests arrive in four or five places. The list lives in one.

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

Related guides