Integration requests: deciding what to build next

In March, a $400,000 deal asks for a NetSuite integration, and it goes on the roadmap that week. Meanwhile, the support team has tagged 312 tickets about a missing HubSpot integration, spelled six different ways, across 140 accounts. Nobody adds them up. The NetSuite integration ships in June, and the customer signs without ever turning it on.

Choosing what to build is the first decision in any embedded integration program, and it decides whether everything after it is worth doing.

What is integration request tracking?

Integration request tracking collects every request for an integration from the places customers make them: lost deals, support tickets, feedback tools and calls. It matches each request to a single named app, counts each account once, and weighs the result by the revenue behind it, so the integration roadmap follows demand instead of whoever asked last.

Why the roadmap follows the loudest deal

1. Requests live in five systems. A lost-deal reason in the CRM, a ticket tag, a feedback note and a call mention never meet.
2. One app has twelve names. “Hubspot”, “HubSpot CRM” and “HS” are counted as three small requests instead of one big one.
3. Noisy accounts count many times. Ten people at one customer asking ten times outweigh fifty customers asking once.
4. New business and retention are mixed together. A lost-deal request and a request from an existing customer measure different things, and one list hides which is which.
5. Customers never hear back. A request that disappears into a list teaches customers to stop asking, so the list gets less accurate over time.

What it costs

Every integration you build is one you maintain for every customer who turns it on. A roadmap that follows the loudest request spends that maintenance on integrations few customers use, while the ones many customers need wait another quarter.

What to fix first

1. Collect requests where customers already make them. Read lost-deal reasons, ticket tags, feedback notes and call mentions where they are, instead of adding another form.
2. Match every request to one named app. Keep a list of apps with their common misspellings, and have a person check anything the matching can’t place.
3. Count each account once. Keep every individual request as evidence, but rank by the number of accounts asking.
4. Weigh by revenue, with new business and retention side by side. They point at different integrations, and both matter.
5. Tell customers when it ships. Close the loop with every account that asked.

The guide to building integration request tracking has the prompts for each step.

What it looks like at Bynder

Bynder’s integration roadmap used to depend on partners asking to join its marketplace. On Tray.ai, it handles custom requests in a month or two instead of waiting for a six-month roadmap, and it went from releasing two or three integrations a quarter to seven or eight in its first phase.

Where it fits

Choosing well only pays off if each integration is built once for every customer and customers keep it running. Adoption data is also the best evidence for the next decision, because it shows which integrations customers use as well as which they asked for.

For the full life of an embedded integration, from choosing what to build to tracking who uses it, see the beginner’s guide to embedded integrations.