Dialer client

A client for a hosted dialer's undocumented web pages that brought the dialer's calls, recordings and reports into the CRM.

Built for
BuildSource LLC
Role
Founder
Status
Past
Stack
TypeScript, Node.js, Postgres

The team dialed on a hosted dialer, and the CRM needed the outcome of every call, and the notes and recording of every call worth pursuing. I mapped the dialer's undocumented web pages in a spec of 690 lines and built a dialer client of about 3,600 lines against them. It signed in, held the dialer's manager seat and pulled the calls into the CRM. It ran until late October, and the feed has been dark since.

What it brought in

calls into the CRM
brought 1,157
the calls worth pursuing
from its full pulls
1,135
from sweeps
22
Code on a dark field from a file named seat-lock.ts: a cap on how often a job may defer and how far back it goes, then the call that puts the job back in the queue with a later run time.The same lines of seat-lock.ts set narrower for a phone, long lines wrapped: the defer cap and delay, then the call that puts the job back in the queue with a later run time.

The seat lock

The dialer allows a single session per account. The client signed in through the dialer's own login form, and when the dialer answered that the account was already in use, it could take the seat over, then checked that the new session was live before trusting it. Every job tried to sign out at the end, so the next could sign in clean.

In June, syncs collided on the login and both failed, and a Postgres advisory lock on the seat went in that day. From September, every job that touched the dialer took the lock without waiting: a job that found the seat taken did not sign in but went back in the queue to try again a little later, up to a cap, so a job waiting for the seat held no database connection while it waited. If a connection died mid-pull, the lock freed itself.

Lines from the client's seat lock, in TypeScript, as they stood when the feed went dark: a job that found the seat taken did not sign in; it went back in the queue to try again a little later, up to a cap.

Pulls and sweeps

After each calling day, a full pull read the call log, the recordings, the notes and profile of each lead, and the report screens. From September, a sweep every few minutes during the dial window brought in only the interested and appointment calls, without recordings.

In the CRM, the recordings went on to transcription and AI call scoring. Lists still went into the dialer by hand, through its own screens: the client only read.

The Lead Tracker CRM

Failing loudly

By the time the feed went dark, its HTTP client had 34 tests, run against a stand-in for the network that answers each request the way the dialer's pages did. Among the rules they held it to:

  • A sign-in that meets a busy account fails loudly, never with a silent takeover
  • A takeover counts only after the new session proves live
  • A session that expires mid-pull gets a single fresh sign-in, then the pull goes on
  • A missing recording writes no file

Contact

For a role, a project or a question about anything here, email me.

An AI phone line that answers questions about my work.

Call my AI
(213) 635-1440