Provisioning readiness scorecard: 15 checks before a multi-site phone rollout
Go-live weeks go wrong in the same fifteen places. Score your current process on each (0 no, 1 partly, 2 yes). Anything under 22 out of 30 means the next big site will cost a week of fire drills; the items you scored 0 are where to start.
One intake format for every order
Why it matters. Orders arriving as emails, PDFs and three spreadsheet layouts cannot be validated, only re-keyed.
What a 2 looks like. A single template or web form; anything else is converted before it enters the queue.
Validation before build, with three outcomes
Why it matters. A build that starts on a bad row fails halfway and leaves a half-built site.
What a 2 looks like. Every order is checked first and sorted into customer must fix, needs review, or clean.
Unique user emails and extensions per site
Why it matters. Duplicate emails collide on softphone logins and voicemail-to-email; duplicate extensions break dial plans.
What a 2 looks like. Validator rejects duplicates across the whole order, not just the row.
Number inventory reconciled
Why it matters. Assigning a DID that is already in use or not yet owned fails silently on some platforms.
What a 2 looks like. The build reads the live inventory and reserves numbers before assigning them.
Port dates known and respected
Why it matters. Ported numbers assigned before the port completes mean dead calls on the port date.
What a 2 looks like. Pending ports are held with a temporary number and swapped automatically on the port date.
Validated emergency address per seat
Why it matters. A typo in a suite number fails validation on go-live day, or worse, passes and is wrong.
What a 2 looks like. Addresses validated against the platform's E911 service before the build; failures go back to the customer.
E911 verified on read-back
Why it matters. On some platforms omitting the E911 field on a write silently clears it.
What a 2 looks like. After every build the seat's E911 record is read back and compared to the order.
Device MACs and models in the order
Why it matters. Phones provisioned without a model get the wrong key layout or no config at all.
What a 2 looks like. MAC, model and the key template are required fields; the validator checks MAC format and uniqueness.
Key layouts per model and role
Why it matters. Hand-programmed BLF keys are the most common day-one complaint.
What a 2 looks like. Key templates exist per handset model and seat role, applied automatically.
Call flow signed off before build
Why it matters. Ring groups, after-hours and greetings built from a verbal description get rebuilt three times.
What a 2 looks like. A one-page call flow per site, approved by the customer, drives the ring group and time-of-day build.
Staged, resumable build
Why it matters. A monolithic script that fails at step 7 of 9 has to be unpicked by hand.
What a 2 looks like. Stages (account, locations, seats, devices, numbers, E911, keys) each re-runnable without touching the ones done.
Dry run, snapshot, rollback
Why it matters. Writes to a live multi-tenant platform without a way back are how outages happen.
What a 2 looks like. Every run can be executed as a dry run; real runs snapshot first and produce a rollback manifest.
Dispatch, shipping and tracking tied to go-live
Why it matters. Go-live dates slip because the tech or the hardware was never scheduled.
What a 2 looks like. Readiness rules flag missing dispatch, tracking or equipment a set number of days before go-live.
Billing hand-off from the build
Why it matters. Seats built and never billed is the most expensive silent failure.
What a 2 looks like. Completing a build posts the seat list to billing (or a ticket to the billing team) automatically.
Status visible to the customer
Why it matters. If status lives in someone's head, every customer call becomes an interruption.
What a 2 looks like. A private status page or ticket note per order, updated by the build itself.
Get the printable scorecard
All fifteen checks on one page with a score column and the "what a 2 looks like" line for each. We email it to you from hello@tightlywired.com. No newsletter unless you ask.
Your email is used to send the scorecard and, if you reply, to answer you. See the privacy page.
Reading your score
26 to 30. Your process is ready to automate; the build will mostly be codifying what you already do. 18 to 25. Fix the zeros first, usually intake validation and E911 read-back; those two remove most go-live surprises. Under 18. Start with one order type and one site, build the intake and validation, and let the rest follow.
The provisioning automation service builds all fifteen into one pipeline: intake, validation, staged build through your platform's API, read-back, hand-offs and a status page. See the walkthrough on a fictional 12-clinic group.
Rolling out sites soon?
A 30-minute call before the next site opening saves the week around go-live. Bring the scorecard; we'll start from your zeros.
Schedule an assessment Pick a time now · or write to hello@tightlywired.com