Multi-tenant operations SaaS with mail, voice, chat, and one ticket pipeline

Operations teams need one system that hosts many tenants without any module assuming a single organisation's data or configuration. The product has to cover real business operations (customers, orders, inventory) alongside support channels that usually ship as separate tools: parsed inbound email, an assistant, IVR call flows, subscription plans, and ticketing. When chat, voice, and mail each pick their own tenancy rules, a reply on one channel can attach to the wrong tenant or open duplicate tickets. The failure mode is a multi-module SaaS where isolation was added after the features shipped.

• Each module must work per tenant with its own configuration and subscription entitlements.
• Tenant isolation has to hold across modules that look unrelated on the surface: mail parsing, chatbot, IVR, ticketing, and plans share the same tenancy rules.
• Subscription plans must be configurable without rewriting each feature path. Feature access, agent seat limits, and ticket volume limits are checked against the tenant, not only at billing time.
• Each tenant picks one inbound-mail method (IMAP or OAuth), not both, to keep configuration and ingestion paths predictable.

• Built multi-tenant SaaS with email parsing, AI chatbot integration, IVR workflows, subscription management, and ticketing modules.
• Designed backend modules supporting tenant isolation and configurable subscription plans.
• Shared MySQL database with tenant key on operational records. Authenticated user from signed JWT; tenant derived from user, never from a client-supplied header.
• Inbound mail handled by a separate background service. Tenant resolved from the support address on delivery. Parsed mail opens tickets automatically.
• Assistant answers from each tenant's knowledge base at query time, with no cross-tenant document access and no per-tenant model training.
• IVR call scripts and tickets persisted in the platform. Telephony delegated externally; IVR interactions open tickets in the same pipeline as email and chat.
• Four roles: platform operator, tenant supervisor, agent, and customer. Subscription lifecycle covers trials, upgrades, downgrades with proration, and cancellation.

• Tenants share one MySQL database. Isolation is a tenant key on operational records, not a database per tenant.
• Authenticated user loaded from a signed JWT. Tenant derived from that user, never from a client-supplied header. Queries and role checks scope work to that tenant.
• Roles: platform operator, tenant supervisor, agent, and customer.
• Inbound mail handled by a separate background service. Tenant configures either IMAP or OAuth. Tenant resolved from the support address the mail was delivered to.
• Each tenant's assistant answers from that tenant's knowledge base, retrieved at query time. No per-tenant model training. A query cannot ask for another tenant's documents.
• Call-handling scripts and the tickets they produce are persisted in the platform. Telephony is delegated to the dialler. An IVR interaction opens a ticket in the same pipeline as email and chat.

• Assistant isolation is the knowledge base loaded for that tenant at chat time, not a separate model host per tenant.
• A tenant picks one inbound-mail method (IMAP or OAuth), rather than running both, to reduce configuration surface and ingestion edge cases.
• Plans combine feature access with usage limits on agent seats and ticket volume, checked against the tenant rather than only at billing time.

• Parsed inbound mail opens tickets automatically, with the ticket built from the content of the message.
• Tickets can originate from email, chatbot, IVR, or manual entry, and keep assignment history and conversation history.
• Subscription lifecycle covers trials, upgrades, downgrades with proration, and cancellation.

Duplicate and threaded inbound email was the hardest part: deciding whether an arriving message opens a new request or belongs to a conversation that already has a ticket. Mail arrives more than once, and replies arrive with varying amounts of usable threading information. A reply whose In-Reply-To header matches a stored message id is attached to that ticket. Otherwise the subject is normalised (reply and forward prefixes stripped) and an open-ticket check runs, with a semantic comparison as a second pass and subject match as fallback. Processed message ids are recorded so the same delivery is not ingested twice.