Engineering Case Study

Designing Automated Telephony Provisioning for Multi-Tenant SaaS

How we automated phone number provisioning for every tenant while keeping onboarding reliable, repeatable, and fully asynchronous.

14 min read·Published July 2026

Overview

One of the platform's core features allows businesses to continue customer conversations through SMS using dedicated phone numbers. Every tenant requires isolated telephony resources before this workflow becomes available.

Provisioning those resources manually was operationally expensive and increasingly difficult to scale as customer onboarding accelerated.

This case study explains how we automated the provisioning lifecycle while ensuring reliability, idempotency, and tenant isolation.

Context

Company-specific implementation details have been generalized. The engineering architecture and design decisions accurately reflect the production system.

The Problem

Provisioning a phone number sounds simple until it becomes part of a production onboarding workflow.

A successful onboarding sequence depended on multiple external operations completing successfully. Failures midway through the process could leave tenants partially configured or require manual intervention.

The provisioning workflow needed to:

  • execute automatically
  • avoid duplicate resources
  • recover safely from failures
  • isolate every tenant
  • avoid blocking customer onboarding

Architecture

Subscription Activated
Provisioning Job
Phone Number Allocation
Messaging Configuration
Database Update
Platform Ready

Provisioning executes asynchronously through background workers rather than during the subscription request itself. This keeps onboarding responsive while allowing retries and recovery when external services experience temporary failures.

Engineering Decisions

Decision 01
Provision asynchronously

External APIs should never sit directly in the critical request path. Moving provisioning into background workers improved reliability while making retries straightforward.

Decision 02
Treat provisioning as idempotent

Provisioning jobs may execute more than once because of retries, deployments, or worker failures. Every operation was designed so repeated execution produced the same final state.

Challenges

External services introduce uncertainty.

Timeouts, temporary failures, and rate limits meant workers needed retry strategies that balanced resilience without creating duplicate resources.

Monitoring and structured logging became equally important as the provisioning logic itself.

Outcome

Provisioning became a fully automated onboarding process requiring no manual intervention.

The system reliably provisions tenant-specific communication infrastructure while remaining resilient to transient failures and supporting safe retries.