How to Move From a Spreadsheet Lead Operation to a Pay-Per-Call Platform

Three tabs open. Google Sheets in one, your buyer's CRM in another, a calculator in the third. You're manually logging call durations, cross-referencing area codes against buyer territories, and reconciling payouts that don't quite match what your tracking numbers show. It's 11pm on a Tuesday.

Most operators running pay-per-call start there — and the spreadsheet works fine until it doesn't. Around 200-300 calls per month, the cracks show. Missed routing opportunities. Payout disputes you can't prove. Calls hitting the wrong buyer because someone fat-fingered an area code rule. (If you're also tracking web leads alongside calls, JustAnalytics handles the attribution side.)

This is a migration guide for operators leaving spreadsheets. Not theory — the actual data mapping, number provisioning, and routing rule translation you need. The goal: move to a real platform without losing your buyer relationships or spending six weeks in parallel-run purgatory.

What You'll Have at the End

By the end of this migration, you'll have:

• All your buyers and their routing rules inside a platform (not a tab)
• Tracking numbers provisioned and mapped to your existing buyer territories
• Call recordings, duration tracking, and source attribution happening automatically
• Payout calculations you can actually defend when a buyer disputes an invoice

Total time: 2-3 weeks if your spreadsheet data is clean. Add a week if it's not.

Prerequisites

Before you start, you'll need:

• Your current spreadsheet with buyer names, payout rates, routing rules, and territory definitions
• Access to provision phone numbers (either through a carrier like Twilio/Telnyx or via a platform's managed service)
• Admin credentials for whatever you're migrating to — VeloCalls, Ringba, CallRail, or similar
• A quiet Friday afternoon for the actual cutover (never cut over on Monday)

Optional but helpful: call recordings from your current setup. They're useful for QA during parallel testing.

Step 1: Export and Audit Your Spreadsheet Data

First, get everything out of your head and into a format a platform can ingest.

Export your spreadsheet to CSV. Most operators have multiple tabs — consolidate them. You need one row per buyer with these columns minimum:

• Buyer name (exactly as you want it in the new system)
• Payout rate (per call or per minute — pick one, be consistent)
• Qualification criteria (minimum duration, geographic restrictions, time-of-day rules)
• Phone number or routing destination
• Territory definition (area codes, zip codes, or state list)

The audit part matters. Open your export and look for:

• Duplicate buyer entries with different payout rates (pick the current one)
• Territory overlaps (two buyers claiming the same area code)
• Stale entries (buyers you haven't routed to in 90+ days)

This cleanup takes 2-4 hours for most operations. Skip it, and you'll spend twice that debugging routing conflicts later.

The spreadsheet operators who struggle most with migration are the ones with "it's in my head" routing logic that never made it to the sheet. Write it down now. If you route Phoenix emergency plumbing to Dave on weekdays but Maria on weekends, that rule needs to exist somewhere a platform can read it.

Step 2: Map Your Data Model to Platform Fields

Every call platform has a slightly different vocabulary. Here's how your spreadsheet columns translate:

Create a mapping document. Seriously. When you're staring at an import screen at 10pm wondering whether "Qualification threshold" means seconds or minutes, you'll thank yourself.

(It's usually seconds. But not always. Platform documentation is weirdly inconsistent on this.)

Most platforms accept CSV imports for buyers. If your platform offers an import template, structure your export to match it — don't assume it will figure out your column names.

One thing that trips people up: the difference between a tracking number (what callers dial) and a target number (where the call routes). Your spreadsheet probably conflates these. The platform won't.

Step 3: Provision Your Tracking Numbers

This is where it gets real. You need phone numbers that belong to you (or the platform), not the network you're leaving.

Two paths here:

Managed carriers (platform handles telephony). Easier setup. You provision numbers directly inside the platform, and they handle the carrier relationship. VeloCalls managed tier runs 4¢/min at Starter, dropping to 2¢/min at Enterprise volume. Ringba and CallRail have similar managed options. VeloCalls tiers step down on lifetime minutes, not monthly volume.

BYOC (bring your own carrier). More control, lower per-minute cost if you have volume. You keep your Twilio or Telnyx account, provision numbers there, and point SIP trunks at the platform. VeloCalls BYOC runs 2¢/min at Starter, down to 0.5¢/min at Enterprise. Extra work upfront, but the saving grows with volume.

For your first migration, start managed. You can always port numbers or switch to BYOC later. Adding BYOC setup to a first platform migration can stretch the timeline by weeks.

Strong opinion: BYOC isn't worth it until you're above 50K minutes monthly. The per-minute savings look great on paper, but the SIP troubleshooting headaches at 2am when your trunk drops? Those don't show up in the spreadsheet.

Provision numbers to match your existing territories. If you've been running 15 tracking numbers across three states, provision 15 numbers in the same area codes. Callers in Phoenix expect a Phoenix number.

Step 4: Translate Your Routing Rules

This is the core of the migration. Your spreadsheet has routing logic — conditional rules that decide which buyer gets which call. Now you need to express that logic in platform-native terms.

Start with the simplest rules first:

Geographic routing. Spreadsheet rule: calls from 602/480/623 area codes go to Phoenix Plumbing Co. In platform terms: create a geo filter on area codes 602, 480, 623 → route to buyer Phoenix Plumbing Co.

Time-of-day routing. Spreadsheet rule: after 6pm, route to After Hours Plumbing. Create a schedule filter: if time > 18:00 local → route to After Hours buyer target.

Capacity/overflow routing. Spreadsheet rule: if Phoenix Plumbing doesn't answer in 30 seconds, try Mesa Plumbing. This is a ring group or waterfall in platform terms. Primary: Phoenix. Timeout: 30s. Fallback: Mesa.

Round-robin or weighted distribution. Spreadsheet rule: split calls 60/40 between two buyers. Weighted routing rule: Buyer A 60%, Buyer B 40%.

Build one rule at a time. Test each rule with a test call before moving to the next. The compound routing bugs — where rule A and rule B conflict — are the ones that cost you money at 2am.

Test calls are annoying. Do them anyway.

A common pattern: operators who've been doing manual routing have rules they apply instinctively that they haven't written down, like sending anything that sounds like a commercial job to the commercial buyer. That's an intent filter. You'll either need conversation intelligence to detect it automatically or a manual review queue. Don't pretend that logic will port perfectly — flag it for human review during parallel testing. If you pre-qualify callers with an IVR, see our guide to A/B testing IVR scripts for pay-per-call.

For more on routing setup, see our home services playbook.

Step 5: Run Parallel Tracking for 7-14 Days

Do not hard-cut from spreadsheet to platform. You will regret it.

Run both systems simultaneously for at least a week. Every call that hits your platform should also get logged in your spreadsheet (manually if needed). At the end of each day, reconcile:

• Did the platform route to the same buyer you would have?
• Did call duration match?
• Did the payout calculation match?

Discrepancies fall into three buckets:

1. Data entry errors — you mistyped a payout rate or area code during import. Fix in the platform.
2. Logic translation errors — the routing rule doesn't work the way you expected. Rebuild the rule.
3. Platform behavior differences — the platform handles edge cases differently than you did manually. Decide which behavior is correct and adjust.

Seven days of parallel usually catches most issues. If you're running more than 500 calls/month or have complex routing, extend to 14 days.

Yes, this means running two systems simultaneously and reconciling both every night. It's tedious. But the alternative — cutting over blind and discovering a routing bug from an angry buyer email — is worse.

During parallel, keep your buyers on the old system. They shouldn't see any change yet — you're validating internally before exposing the new stack.

Step 6: Notify Buyers and Cut Over

Once parallel testing is clean for 5+ consecutive days, you're ready to cut over.

Give buyers 2 weeks' notice. Send them:

• The new call recording URL format (platform-specific)
• Any changes to their reporting dashboard access
• Confirmation that payout rates and routing rules are unchanged
• Your contact info for the first 48 hours post-cutover

Cut over on a Friday afternoon, after your peak call volume. You want a quiet weekend to catch any issues before Monday traffic hits.

On cutover day:

1. Disable routing in your old system (or port numbers if applicable)
2. Enable the platform routing you've been testing
3. Watch the first 10-20 calls live
4. Check buyer confirmations that calls are landing

If something breaks, you've got the weekend to fix it. If everything works, you've got the weekend to relax.

(You probably won't relax. You'll check the dashboard every 30 minutes anyway.)

Common Errors and How to Fix Them

"Calls routing to wrong buyer"

Cause: Area code overlap in your routing rules. Two buyers both claim 480.

Fix: Check your geo filters. Most platforms evaluate rules in order — put the more specific rule first, or use explicit exclusions.

"Call duration shows 0 seconds"

Cause: SIP handshake completed but audio path failed. Usually a BYOC configuration issue.

Fix: Check your SIP trunk settings. Codec mismatch and NAT traversal are the usual culprits. If you're on managed carriers, contact support — this shouldn't happen.

"Payout calculations don't match my spreadsheet"

Cause: Qualification threshold mismatch. Your spreadsheet counted from answer; the platform counts from connect.

Fix: Verify the platform's duration measurement method and adjust your threshold so both systems measure the same thing.

"Buyer says they're not getting calls"

Cause: Ring-to number is wrong, or their phone system is rejecting the caller ID.

Fix: Test-call the ring-to number manually. Check if the platform is passing caller ID through — some buyer phone systems block calls with unfamiliar ANIs.

Next Steps

You're on the platform. Now what?

Start tracking metrics you couldn't track in a spreadsheet. Call source attribution by publisher. Close rate by buyer. Revenue per call by time slot.

Turn on features you didn't have before: real-time bidding if you have multiple buyers competing for the same territory, visual IVR flows if you need pre-qualification, conversation intelligence if intent detection was manual before. If you buy traffic to drive calls, ClickzProtect screens out bot traffic before it reaches your landing pages.

The operators who get the most from migration are the ones who don't stop at "it works like the spreadsheet did." The spreadsheet was a ceiling. Now you can build.

One caveat: the first month post-migration, you'll probably miss the spreadsheet's simplicity. Everything's in one place, you could edit a payout in 2 seconds, no login required. That feeling passes once you realize you haven't had a payout dispute in weeks because everything's recorded.

Frequently Asked Questions

How long does a spreadsheet-to-platform migration typically take?

Plan for 2-3 weeks if you're running under 500 calls per month and have clean data. Week one is data mapping and number provisioning. Week two is routing rule setup and parallel testing. Week three is cutover and buyer notification. If your spreadsheet has duplicate buyer entries or inconsistent naming, add a week for cleanup. The operators who drag this out to 8+ weeks are usually the ones trying to migrate and optimize simultaneously — don't do that.

Can I keep my existing phone numbers when migrating?

Depends on who owns them. If you purchased tracking numbers through Twilio, Telnyx, or Bandwidth directly, you can port them to a new platform or use BYOC mode to keep routing through your existing carrier. If a network issued the numbers, those numbers belong to the network — you'll need fresh numbers and a redirect period. Budget 2-4 weeks for porting if you go that route. Provisioning new numbers and running both systems in parallel is usually faster.

What's the minimum call volume where a platform makes sense over spreadsheets?

Around 150-200 calls per month is where the math usually tips. Below that, a well-structured spreadsheet with manual routing can work — the labor cost is manageable. Above 200 calls, you're spending 10+ hours a month on manual tracking, missing routing opportunities, and your error rate on payouts starts climbing. If you're routing to more than 3 buyers or running multiple verticals, drop that threshold to 75-100 calls. Complexity matters more than volume.

Do I need to rebuild my buyer relationships from scratch?

Not if you handle the transition right. Export your buyer list with all routing rules, share the migration timeline 2 weeks before cutover, and run parallel tracking during the transition so payouts stay accurate. The buyers who matter won't care what platform you use — they care that calls keep flowing and invoices stay correct. Send them the new call recording URLs and source attribution on day one. Operators usually lose buyers only when they surprise them with a platform switch mid-month.

Try VeloCalls for Your Vertical

Call tracking + pay-per-call platform built for HVAC, plumbing, roofing, PI lawyers, Medicare brokers, and insurance. Smart routing, real-time bidding, visual IVR builder, AI conversation intelligence. Per-minute pricing — Managed starts at 4¢/min, BYOC at 2¢/min, both drop as you scale.

See pricing → · Book a demo