Support replies that open the right screen.
Instead of 'tap Profile, then Settings, then Privacy', send a link that opens the app on that screen, and still lands there after a reinstall.
- Who runs it
- Product
- Time to set up
- Minutes, after the SDK
- Plan
- Free
One link per screen, saved as a snippet.
Make a link per destination screen and save it in your help desk. The path is the screen; the source tag says it came from support. Nothing personal in it, so it's safe to reuse anywhere.
- Reuse the same links in the help centre, FAQ and chatbot.
- Change the screen later without editing old replies.
The exact screen, one tap from the reply.
The customer taps the link in your reply and lands on the screen they need, logged in. No route to follow.
- Works on iPhone and Android.
- After a reinstall too.
Fewer second replies.
Compare repeat contacts on tickets with a link against tickets that described the route, using your help desk's own numbers. LinkTrail shows which links get opened, and how often.
- Opens per support link.
- Which screens customers get sent to most.
One-time setup, then it's all yours.
Your developer adds the LinkTrail SDK once and routes on the link's path. Any screen with a route can then get a support link, without a release.
LinkTrail.onLink(link => {
// link.customData = { src: "support", macro: "data-export" }
router.navigate(link.path);
});The full walkthrough: Support deep links: 'go to Settings → Privacy → Export' loses half your readers
Every support team has a set of replies that describe a route through the app. 'Tap your profile, then Settings, then Privacy, then Export data.' The person reading it is on their phone, with the app one swipe away, following a four-step description of taps they could be making. Some get lost at step two and reply again. That reply is a ticket you paid for twice.
What problem does this solve?
The reply should contain a link that opens the app on the screen the reply is describing. If the person has uninstalled, the same link takes them through the store and lands on that screen after. And because support links are tagged, you learn which screens people can't find — which is a product problem wearing a support costume.
How do you set the links up?
A link per destination screen, saved as a snippet in the help desk. The deep link path is the screen; the source tag says it came from support and which macro it was in. There's nothing per-user in the payload, so the links are static and safe to share.
{
"deepLinkPath": "/settings/privacy/export",
"customData": {"src": "support", "macro": "data-export-how"}
}Where else does the same link belong?
| Surface | What changes |
|---|---|
| Help centre articles | Same link; the source tag says help-centre instead of support |
| In-app FAQ | Opens the screen directly; still tagged, so you learn what the FAQ is for |
| Chatbot replies | The bot can hand off to the screen instead of explaining the route |
| Release notes | 'Try it here' opens the new feature rather than describing where it is |
One link per screen, reused everywhere that screen is mentioned. The tags tell you which surfaces send people there.
What does the data tell you?
The screens with the most support-link taps are the screens people can't find on their own. That is a navigation problem, and it's now measured. Teams that do this usually find that two or three screens account for most of the taps, and moving those screens one level up in the app removes a category of tickets.
Which metric should you watch?
Repeat-contact rate on tickets that contained a deep link versus tickets that described a route. If the link cuts the second reply, it's paid for itself; the product insight from which screens get linked most is the bonus.
Which teams own support deep linking?
- Mobile product teams
Which LinkTrail features does support deep linking need?
- Re-engagement links
- Smart routing
- Per-link source and placement tagging
Support link questions.
How do you add deep links to support replies?
Create one link per destination screen and save it as a snippet in the help desk. The deep link path is the screen and the source tag records that it came from support and which macro; nothing per-user goes in the payload, so the links are static and safe to share.
Where else should support deep links be used?
Anywhere the screen is mentioned: help-centre articles, the in-app FAQ, chatbot replies and release notes. Reuse the same link with a different source tag so you can see which surfaces send people to each screen.
What metric shows support deep links are working?
Repeat-contact rate on tickets that contained a deep link versus tickets that described the route. The screens that get the most support-link taps also show which parts of the app people can't find on their own.
If you're doing this, you'll probably want these.
Email links
Opens the app if it's installed, the store if not. No more newsletter links opening in Safari on phones that have the app.
SMS campaigns
Short links that fit in a text and open the app, not the browser.
Onboarding that matches the ad
If the ad promised 20% off, the first screen shows 20% off. Nobody has to find the code again.
Make your first support link.
Free for your first 5,000 users. No card, no sales call.