What to Ask About Implementation Before You Sign

Implementation is the phase that determines whether a communications platform succeeds. Yet most buyers take it up only after they sign the contract.

That order is backwards for a simple reason. Before signature you have leverage and the vendor has an incentive to be specific. After signature the same questions get slower answers, and anything not written down becomes a negotiation you have already lost.

Fifteen questions across five areas. Treat three answers as warnings.

Scope and sequence

1. What is included in implementation, and what is billable?

Configuration, number porting, device provisioning, training, integration work, and support after launch are each sometimes included and sometimes not. Assume nothing.

Good answer: an itemized scope document listing inclusions, with hourly or fixed rates for exclusions.

Warning answer: "Implementation is included," with no scope attached.

2. Is the deployment phased by location, or is there one cutover?

For a multisite organization, a single cutover date concentrates every unknown into one morning. A phased approach lets the first site absorb the surprises the plan did not anticipate.

Good answer: a phased sequence with a named pilot site and a defined interval before the next wave.

Warning answer: "We'll cut everyone over on the same weekend." Treat this one as a warning.

3. Who chooses the pilot site, and on what basis?

The right pilot is representative rather than easy. A small, simple, well staffed site produces a smooth cutover and teaches you nothing about the complicated ones.

Good answer: a discussion about which site best represents your hardest configuration.

Warning answer: the smallest site, chosen to make the first milestone look good.

4. What has to be true before we can start?

Network readiness, site surveys, device decisions, and a directory of users are usually prerequisites. If those are your responsibility and nobody says so, the schedule slips and you take the blame.

Good answer: a written prerequisite list with owners.

Warning answer: "We'll figure that out in kickoff."

5. What is the rollback plan if a cutover fails?

Good answer: a documented sequence with a decision point, a named decision maker, and a time limit.

Warning answer: "That hasn't happened."

Number porting

Porting is the transfer of existing telephone numbers from one carrier to another. It is the single most common cause of implementation delay. It deserves its own section, because most of it sits outside your vendor's direct control.

6. Who submits the port request, and what do you need from us?

Good answer: a specific list, usually including a recent bill, a letter of authorization, and an exact account name and service address as they appear with the losing carrier.

Warning answer: "Just send us your numbers."

7. What happens when a port is rejected?

Rejections are routine. They come from mismatched addresses, account names that do not match, pending orders on the account, or a contractual term with the losing carrier.

Good answer: a described resubmission process, an owner on the vendor side, and an estimate of the additional cycle.

Warning answer: a rejection rate quoted as very low, without a process.

8. Which numbers cannot port cleanly, and what do we do about them?

Some numbers do not port cleanly: numbers tied to alarm lines, elevator lines, fax lines bundled with other services, and numbers in certain rate centers.

Good answer: an audit of your number inventory before signature, flagging the risky ones.

Warning answer: the assumption that everything ports.

9. Can we run in parallel during the port?

Running old and new in parallel for a period is the difference between a bad morning and a bad quarter.

Good answer: a described parallel period with forwarding in place.

Warning answer: a hard cutover with no overlap.

Configuration

10. Who configures routing, and who signs it off?

Good answer: the vendor builds from your workflow documentation, and a named person on your side approves before go-live.

Warning answer: the vendor configures to their standard and you discover the differences afterward.

11. Will you configure site templates, or one site at a time?

If you have more than three locations, a template is what prevents configuration drift from starting on day one.

Good answer: a template built with you at the pilot site and applied to subsequent sites.

Warning answer: each site configured independently by whoever is available.

12. What do retention, permissions, and emergency calling look like at launch, and who approved them?

For a regulated buyer, this is not an operations question. It is the state of the record system at the moment it starts holding records

Good answer: documented settings, reviewed by whoever owns compliance, before the first call.

Warning answer: defaults, revisited later.

Training and go-live

13. Who is trained, when, and how far ahead of cutover?

Training three weeks before go-live is training that has been forgotten. Training the morning of go-live is training that competes with a live cutover.

Good answer: sessions by role close to each site's cutover, with administrator training separated from training for everyone else.

Warning answer: one webinar for everyone.

14. Who is on site or on call during cutover, and for how long after?

Good answer: a named contact, availability defined in hours, and a stated period of elevated support after each site goes live.

Warning answer: the standard support number.

15. Who owns the relationship after launch, and when does the handover happen?

Implementation teams and support organizations are usually different groups. The handover is where context gets lost.

Good answer: a described handover with a joint period and a named ongoing contact.

Warning answer: "You'll go through support like everyone else," delivered as though it were reassuring.

The three warning answers

Three responses should change how you read the whole conversation.

"We'll cut everyone over on the same day." For a multi-site organization, this concentrates every unknown into one morning with no opportunity to learn from the first site.

"That hasn't happened." In response to a rollback question, this means either it has and they are not saying, or it has not and there is no plan. Both are the same answer operationally.

A quoted implementation duration with no conditions attached. Implementation length depends on porting, network readiness, site count, and how quickly you approve configuration. A vendor quoting a flat number is quoting a marketing figure, not a plan.

The one question that matters most

If you ask nothing else, ask this: what does a failed cutover look like, and how do we get back?

The answer tells you whether the vendor has done this at your complexity, and whether they have thought past the happy path. It also tells you whether the people answering are the people who will be there. A vendor with a real answer will describe a sequence, name a decision point, and tell you what it costs.

That is worth more than any feature comparison in the evaluation.

How we approach it at PanTerra

We hold ourselves to the same list. Every PanTerra deployment is assigned a dedicated project manager, based in the U.S., who owns the implementation from kickoff through launch.

For multisite customers, the rollout plan is the customer's choice. We can phase by location, beginning with a pilot site the customer selects, often the one with the most demanding configuration. We can also bring every location live on the same day, and we have done exactly that for many customers. When we do, it is because the discovery, training, and rollback planning described above was completed first. That preparation is what makes a single launch date a strength rather than a warning.

If you are evaluating us, ask us every question above.

Frequently Asked Questions

What causes phone system implementation delays?

Number porting is the most common cause, usually through rejections for mismatched account details or pending orders with the losing carrier. Network readiness and slow configuration approval on the buyer side are the next two.

How long does number porting take?

It varies by carrier, number type, and whether the request is accepted on first submission. Rather than accepting a duration, ask what the vendor does when a port is rejected, who owns the resubmission, and whether you can run in parallel during the transition.

Should all sites go live on the same day?

For a multi-site organization, a single cutover concentrates every risk into one morning and removes the chance to learn from the first site. A phased sequence with a representative pilot site is safer, and a vendor proposing a single date should be asked why.

What should be in an implementation scope document?

Itemized inclusions and exclusions with rates, a prerequisite list with owners, the site sequence, the porting process including rejection handling, the training plan by role, and the rollback plan with a named decision maker.

Who is my contact during implementation, and after?

Ask for a named contact through go-live and a described handover to ongoing support, including whether there is a joint period. Implementation and support are usually different teams, and the handover is where context is lost.

Why ask these questions before signing?

Because that is when you have leverage and the vendor has an incentive to be specific. After signature, anything not written down becomes a negotiation you have already lost.

Quick Answers

• Biggest delay cause: number porting, largely outside the vendor's control. Ask about rejections, not timelines.
• Single launch date across sites: a warning, not a strength.
• Pilot sites should be representative, not easy.
• Three warning answers: one cutover date, "that hasn't happened," and a duration with no conditions.
• The one question: what does a failed cutover look like, and how do we get back?