✨ Tiger Productization - Research the work needed to serve users outside SSW

Hi Team!

Pain

Tiger only works inside the SSW tenant today, and we have no costed answer for what it would take to turn it into a product external customers could use.

The core blocker is access to transcripts. SSW granted our own app permission to read all transcripts - a single-tenant app registration using client credentials (OnlineMeetings.Read.All + CallRecords.Read.All) plus a Teams Admin-configured Application Access Policy. An external customer has no equivalent path, and GRAPH_TENANT_ID / GRAPH_CLIENT_ID / GRAPH_CLIENT_SECRET are single values in Key Vault, so the whole system assumes exactly 1 tenant.

That is not the only tenant-bound piece. Without a survey and an estimate we cannot plan, price, or commit to productising Tiger.

Acceptance Criteria

This is a research spike. The deliverable is a written findings document plus an effort estimate - no production code required.

1. An inventory of every part of Tiger that assumes the SSW tenant, and what each would need to work for an external customer. Including but not limited to:
   • The single-tenant Graph app registration, client-credentials flow, and Application Access Policy
   • The Graph change-notification subscription and its renewal job
   • The Logic App (TigerTeams) that sends Teams notifications, and its hand-configured connections
   • Any future Teams app / bot (see #128) and email ingestion (see #136) entry points
   • Portal Static Web App sign-in, which is currently pinned to the SSW tenant GUID
   • Cosmos DB, blob storage, and dashboard hosting, which are a single shared instance with no tenant boundary
   • Deployment and infrastructure (Bicep, Key Vault secrets, DNS) - what is per-customer vs. shared
2. Options documented for how an external tenant would grant Tiger access to its transcripts, with trade-offs - e.g. multi-tenant app registration with admin consent, per-customer app registration, delegated per-user consent, or customer-supplied transcript upload only. A recommendation is given.
3. Data isolation options documented for transcripts, analysis output, and dashboards (shared store with a tenant key vs. store per customer vs. full stamp per customer), with the security implications of each.
4. Identity and authorization approach documented for external users - how they sign in, and how we stop a user seeing another customer's dashboards.
5. Customer onboarding path documented end to end: what an admin at a new customer has to do, and how much of it we can automate.
6. Compliance and privacy considerations identified - transcript data residency, retention, deletion on request, and what a privacy policy would have to state.
7. Commercial considerations identified at a high level - per-tenant cost drivers (Claude token spend, storage, Container Apps) and what a pricing/metering model would need to measure.
8. Anything else the research surfaces that is not listed above is captured in the findings document rather than dropped.
9. Effort estimate for the recommended path, broken into phases and sized in sprints, so the work can be scheduled.

Thanks!
@

Start by tracing the tenant-specific configuration and deployment surface: the Graph subscription and renewal job, Logic App TigerTeams, Portal Static Web App sign-in, Cosmos DB, blob storage, dashboard hosting, Bicep, Key Vault, DNS, and referenced entry points #128 and #136. Document the external-access, isolation, identity, onboarding, compliance, commercial, and deployment options with trade-offs. Done means a written findings document with a recommendation and a phased effort estimate in sprints.