Teams static tab pinned before configurable detour
Ship one strong static tab for the first read, because Teams pins the static tab by default when you also offer a configurable tab in the same scope.
Why this can grow a startup
Teams gives builders a subtle lesson about first impressions. When both a configurable tab and a static tab exist in the same scope, Teams pins the static tab by default. That means the tab most users see first should explain the job, the next step, and the proof that the app belongs there. A configuration flow can still exist, but it should not have to carry the whole introduction. The default-pinned surface is doing branding, onboarding, and qualification at once.
Company example
Microsoft's tabs documentation says that if an app has both a configurable tab and a static tab for a scope, Teams pins the static tab by default.
Source and metric
Source: Microsoft Learn: Tabs in Microsoft Teams
Teams defaults to pinning the static tab first when both static and configurable tabs exist in a scope.
When to use it
Use this when Onboarding, Brand Trust, Product is relevant to teams apps, tabs, first-run UX and you can run a bounded test with a low budget.
When not to use it
Do not use it as a substitute for customer evidence, a clear owner, or a measurable stop condition. Local platform rules and market behavior still need checking.
Founder checklist
- Read Microsoft Learn: Tabs in Microsoft Teams and identify what is directly supported.
- Choose one channel context: Onboarding, Brand Trust, Product.
- Define the test around Teams defaults to pinning the static tab first when both static and configurable tabs exist in a scope..
- Set an owner, evidence window, and stop condition before launch.
Explore the context
Apply this with an operator
Choose product surfaces that compound distribution without hiding weak activation or retention.