Outcome. A lead captured through the mobile app reaches the team trained on the app experience, and a web-form lead reaches the standard web team, instead of both going through one generic queue that treats the two channels the same.
flowchart TD
A[Contact created via mobile app or web intake] --> B{Lead Channel?}
B -->|mobile-app| C[Rotate to mobile app specialist team]
B -->|web-form| D[Rotate to standard web-lead pool]
B -->|web-chat| E[Rotate to chat-qualified lead pool]
B -->|blank| F[Rotate to standard web-lead pool + notify sales ops]
C --> G[Set routed date, notify owner, create call task]
D --> G
E --> G
F --> G

When to use it, when not to
- UseUse it when mobile app leads and web leads genuinely need different follow-up (different product context, a different onboarding flow, or a team specifically trained on the app).
- UseUse it when the mobile app and the website use separate, distinct HubSpot forms or a distinct integration path, so the channel is knowable at intake without guessing from a browser string.
- SkipDo not use it if a single form serves both channels identically embedded in the app's webview and the website; there is no reliable signal to branch on in that case, fix the intake separation first.
- SkipDo not use it expecting a native "device type" contact property; standard analytics device data exists at the page-view and session level, not as a persistent contact property.
or the lead routing pack, 39 EUR
One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.





