Tests that make no real calls

The platform can run in a test mode before real calls occur. One switch sends each call to a simulated phone network. The simulation sends the same signed messages as the real network, with realistic random outcomes. No real phone rings.

The simulator

A small, separate service simulates the voice provider, the phone network, and the analysis model. The analysis model is the component that reads each finished conversation and reports what occurred on the call. When you set the test switch, the platform sends each part of a call to the simulator. The route to the real providers stays disconnected.

What makes the simulation accurate

A test is useful only if the simulation is accurate. Four properties make the simulation accurate:

• The same signed messages. The simulator's event reports carry the same type of cryptographic signatures as the reports from the real providers. Thus the platform's verification and record-keeping run fully during a test. No check is turned off, and no message skips a check.
• Realistic results. The simulator does not give each call a good outcome. Two figures set the mix, and both are read from today's real pilot: about 1 dial in 20 gets answered, and about 1 in 14 of those answered calls ends in a decisive result — a booking, a lead marked interested, a lead marked not a match, a request to stop calling, or a live transfer. Out of 1,000 test calls, the approximate mix is:

  What happens	Out of 1,000 test calls
  Nobody answers	648
  Line busy	173
  The call fails	129
  Voicemail	34
  Wrong number	8
  The call's analysis never arrives	5
  A decisive result — a booking, an interested lead, a lead marked not a match, a stop-calling request, or a live transfer	3

  A first read of this table can look bleak. It is deliberate: it matches how few of a broker's inactive leads answer at all, and it is why the platform's value is reached over many calls, not one.
• The simulation includes the analysis step. The analysis step reads a finished conversation and reports what occurred on the call. In real operation, this step costs money and can occur only after a real conversation exists. The simulator does this step too: it reads the test transcript and returns judgments that agree with the selected outcome. A booked meeting returns as interested and qualified, and a “stop calling me” returns as not interested. Thus the dashboards for this step show test data in the same way as real data, at no cost.
• Intentional faults. The simulator sends approximately one message in ten two times. It sends approximately one message in twenty out of order. A few messages in each hundred carry a forged signature or a timestamp that is too old. These faults are intentional, because the real phone network causes the same faults. Thus the test proves the platform's checks for duplicates, message order, and forged signatures.
• A simulated number-reputation check. The pool's reputation scoring service is billed per number checked, so this leg is simulated too — fetch, store, and chart the result — before a single real check is billed against the pool.
• The multi-agent split. A rehearsal of a campaign with more than one voice agent splits its leads across the chosen agents the same way a real campaign does, so a comparison between agents is tested honestly before any real money is spent.
• Realistic compliance signals. A small share of simulated calls fail the platform's newest quality checks on purpose: about one call in forty answers too slowly, about one call in a hundred produces no recording, and about one call in a hundred reports a claim the agent must not make. Thus these checks are proven to catch a real failure, not only proven to run without error.

One more property: the same test gives the same result. The simulator makes its random choices from a fixed starting number, so each run repeats the same outcomes. Thus a defect found in a test occurs again on each run, until a fix removes it.

Safety controls

Safety controls keep the test mode separate from real operation:

• The switch resets to off on each page load. You must select the test mode again each time.
• If a test cannot connect to the simulator, the test fails with an explicit error. The platform does not place a real call in that case.
• The simulator keeps no records of its own, and it starts only when its target is a test platform.
• A rehearsal's simulated dials pass even while an emergency stop holds real dialling off. A simulated dial never reaches a real phone line, so a stop built to protect a real line and real spend has nothing to protect there. The platform records each bypass, so which simulated dials ran past an open stop stays a question you can answer.
• The platform labels each test call in the record, and each real-traffic view filters the test calls out. Thus spend reports, do-not-call lists, and pilot metrics contain no test data. One narrow, intentional exception exists: the campaign simulation writes labeled rows to check its own results. A section below describes this exception.

The campaign simulation

A larger test exists: the campaign simulation. It moves each assigned lead through its full calling journey — the release plan, the chosen calling style's curve of calls, and its reserve days — in minutes rather than weeks. The simulation includes the gate checks and the outcomes. It is fast because its clock is a stored value, not a real timer. The simulation does not wait for the next day; it computes the next day's actions immediately.

The results show each day: the number of leads released, called, and resolved, and the outcome of each lead. The results also show each skipped day and the reason for the skip, down to the name of a public holiday.

You start the simulation from the campaign screen before a campaign goes live. The simulation shows the full programme before the first real call: the pace, the date the lead list becomes empty, and the mix of outcomes.

You also choose how fast the simulated clock runs:

• 100× speed removes all the waiting between simulated business days, so a ten-day programme finishes in minutes. This is the default, because a rehearsal exists to remove the wait.
• 10× speed leaves 2.4 hours of real time between simulated days, for watching the programme unfold at a tenth of its true pace.
• 1× speed leaves a full 24 hours between simulated days: a live rehearsal, running in real time.

The platform refuses to run a 100× simulation on the real, live environment unless a person deliberately overrides the refusal. At that speed, the simulation drives every outside connection the platform uses at its fastest possible rate, for the whole programme, and the platform will not do that by accident.

The simulation writes real records, then removes them

Each simulated outcome writes to the same records as a real call. A simulated conversion, a simulated wrong number, and a simulated “stop calling me” each write a record with a test label. If a test does not write these records, the do-not-call list, the review queue, and the related dashboards stay untested until the first real call.

• A simulated lead's status moves through the same stages as a real lead's status: released, worked, resolved. Thus the funnel view shows a test in the same way as a live programme. The platform restores the status after the test.
• A simulated “stop calling me” writes a real, labeled entry to the do-not-call list. The safety gate obeys the entry for the remainder of the same test. Thus a simulated opt-out on day 3 stops the simulated call on day 4. The test must prove this behavior before a real caller depends on it.
• A simulated case that needs a person's judgment goes into the real review queue, with the same test label.
• The simulation spreads its calls across the client's real pool of phone numbers, in rotation. The simulated calls use no real daily capacity. Thus the number pages show the spread of a real programme across the pool. The simulated reputation readings of those numbers carry the test's own id, so a rehearsal never changes a real number's record or its state.
• Opening a simulated call's record plays a short recorded sample through the same player a real call's recording uses, so a reviewer checks the same screen either way.

Each real-traffic view filters out each labeled row. One discard action deletes each row that the test wrote, and this includes the lead status changes. After the deletion, the account is in the same state as before the test. A scheduled weekly cleanup also removes test rows older than a set number of days, so forgotten test data does not grow forever even without a manual discard.

The test of the pacing engine

The campaign simulation proves outcomes. It does not prove the pace, because it compresses weeks into minutes by design. A test of the pace must run in real time. The test must show that the pacing engine and its emergency stops work correctly in continuous live operation, as they do for a real client.

For this test, the platform keeps a permanent test client. The test client's campaigns have a test label, and they run on the real system. The real pacing engine runs for this client each minute. The real per-lead calling engine calls its leads on schedule. The real safety gate examines each call attempt. Only the call itself goes to the simulated providers.

The pacing engine is the one part that the campaign simulation cannot test, so this test client runs at all times. This test does not write the special records that the campaign simulation writes. Its simulated stop requests and its review cases do not go into the do-not-call list or the review queue. The platform labels each of its calls and filters them out, the same as a single test call.

A prospective client's sandbox rehearses on its own

Every demo organization — the sandbox a prospective client explores before they sign up — keeps its own rehearsal running, with no person starting it. Every thirty minutes, a scheduled job:

1. checks a platform-wide switch, and does nothing further if the switch is off;
2. checks whether that sandbox already has a rehearsal in progress, and waits for the next thirty minutes if so;
3. clears the rows the previous rehearsal wrote, and puts every seeded lead back to a dialable state;
4. starts a fresh rehearsal on the sandbox's seeded campaign.

Thus a prospective client who opens their sandbox at any hour finds a dashboard, an Opportunities list, and a Pipeline screen with current, plausible results — not the empty screen an untouched sandbox would otherwise show. A single platform-wide switch can stop every sandbox's rehearsal loop at once, for maintenance or for a cost concern.