Back to Portfolio
AI Platform
In Pilot — First Customer Workflow RunningCallIntell — AI Call Synopsis & Quality
Every call summarised into the CRM, without anyone listening
Speaker-labelled transcripts with word-level timestamps
Every synopsis point links to its moment in the audio
Idempotent CRM writes — retries cannot duplicate
Overview
CallIntell turns recorded phone calls into reviewed, structured CRM records without anyone listening to the call. A six-stage queue-backed pipeline fetches the recording, transcribes it with speaker labels and word-level timestamps on serverless GPU, strips personal identifiers before any text reaches a language model, matches the call to its CRM record, and generates a schema-validated synopsis — outcome, commitments, objections, price discussed — with every point linked to the second of audio it came from. Spoken follow-up phrases such as “call me in ten days” are resolved into dated CRM tasks in the customer's own time zone, with the verbatim wording kept alongside. Anything the system is not confident about routes to a human review queue rather than being guessed, and CRM writes are idempotent so a retry cannot duplicate a note or a task. Built on Next.js, BullMQ on Redis, PostgreSQL with Drizzle, WhisperX with diarization, Microsoft Presidio redaction and Claude, with passkey and TOTP sign-in, an append-only audit log, per-company isolation and usage metering. Deployed and running the first customer workflow; not yet opened as a public product.
Somebody has to listen to every call. That does not scale, and it is the first thing cut.
A team listens to calls and types up what happened.
On a floor of any size, summarising calls is a full-time job for a group of people. They listen at double speed, skim, and still cannot cover everything — so coverage quietly becomes a sample rather than the whole.
The CRM record is written from memory, hours later.
By the time a summary is typed, the detail has gone. What the customer actually committed to, the price that was quoted, the exact words they used about calling back — the specifics that matter are the first to be lost.
"Call me in a couple of weeks" never becomes a task.
Follow-up dates live in the recording and in somebody's head. Unless a human converts the phrase into a dated task on the right record, the callback does not happen and nobody notices.
Recordings contain data that must not reach a model.
Customers read out card numbers, bank details and government identifiers on the phone. Sending raw transcripts to a language model is the easy way to build this, and the wrong one.
CallIntell does the listening. People check the few results the system is not sure about, and the rest is written to the CRM unattended.
What changes once it is running
The outcomes that actually move the needle
Every call gets a synopsis, not a sample.
Coverage stops being a function of how many people are available to listen.
Reviewers edit instead of writing.
Confident results pass through untouched. The queue contains only the outcomes, dates, prices and commitments the system flagged as uncertain.
Follow-ups become dated tasks automatically.
A spoken "in about ten days" is resolved against the call date and the customer's time zone and lands as a task on the right record, assigned to the right agent.
Claims are checkable in seconds.
Every point in a synopsis links to the second of audio it came from, so verifying is a click rather than a re-listen.
Personal data never reaches the model.
Redaction happens in the transcription worker, before the text is sent anywhere else.
The numbers trace back to the calls.
Minutes are metered as they are processed and invoices are generated from that record, not estimated.
Key Capabilities
What we designed, built and shipped
Six-stage retryable pipeline: ingest, transcribe, match, synopsise, review, CRM write-back
PII redacted in the transcription worker, before any text reaches a language model
Spoken follow-ups resolved to dated CRM tasks in the customer timezone
Low-confidence results queue for a human instead of being guessed
Technology Stack
Chosen so the expensive part scales with usage and the rest costs nothing when idle.
| Layer | Technology | Why |
|---|---|---|
| Review app | Next.js, React, TypeScript | Server-rendered call queue, transcript-with-audio review, and the per-company settings screens. |
| Pipeline | BullMQ on Redis | Six independent stages with per-stage retries, so one bad call does not stall or re-run the others. |
| Database | PostgreSQL with Drizzle ORM | Typed schema and migrations shared by the worker and the web app from one package. |
| Transcription | WhisperX with diarization, on serverless GPU | Speaker labels and word-level timestamps; serverless means GPU cost follows audio minutes rather than wall-clock time. |
| Redaction | Microsoft Presidio with custom recognisers | Strips identifiers before the transcript leaves the worker — including numbers read aloud in groups, which speech recognition writes as digits separated by pauses. |
| Language model | Claude, with schema-validated output | The synopsis comes back as a validated object — outcome, commitments, dates — not as prose that cannot be reported on. |
| Audio storage | S3-compatible object storage | Stateless workers and pre-signed, expiring URLs instead of files on a server. |
| Telephony and CRM | Connector per system | Recording retrieval and CRM write-back sit behind one interface each, so a second telephony or CRM system is an addition, not a rewrite. |
| Dates and time zones | Luxon | Relative phrases resolve in the customer's zone, which is the whole difference between a useful callback and a missed one. |
| Authentication | WebAuthn passkeys and TOTP | The review app holds call recordings; password-only access was not adequate. |
| Hosting | Docker with Caddy, nightly backups | Runs on a single box or in a customer environment, with automatic certificate renewal. |
How it works
What happens between a call ending and a task appearing
1
The call ends
A webhook fires. A poller sweeps for anything the webhook missed, because recordings are not always ready immediately.
2
The recording is stored
Audio is streamed into object storage. Already-seen calls are detected and skipped.
3
It is transcribed and redacted
A GPU worker produces a speaker-labelled transcript with word timestamps, then strips personal identifiers — before any of it is sent onward.
4
It is matched to a CRM record
The tenant's recording-naming pattern is parsed first, then the caller number. No confident match means the unmatched queue, not a guess.
5
A synopsis is generated
The call type selects a template. The model returns a validated structure: outcome, next actions, objections, commitments, price discussed — each point carrying the timestamp it came from.
6
The follow-up date is resolved
A spoken phrase becomes an absolute date in the customer's time zone, with the verbatim wording kept beside it. Anything vague is flagged.
7
Confidence decides the route
Uncertain fields go to the review queue with the evidence attached. Everything else continues unattended.
8
The CRM is updated
A note on the record, the outcome fields, and a follow-up task on the resolved date assigned to the agent. The write is idempotent, so a retry changes nothing.
Deployment
How it runs
Managed by eSparks
We host and operate the pipeline and the review app. Telephony and CRM credentials are held encrypted per company.
In your own environment
The whole stack is containerised and runs on a single machine, so it can sit inside your infrastructure where recordings must not leave it.
Per-company configuration
Synopsis templates, scorecards, roles, users and integration credentials are all configured per company within one deployment.
Integrates with
- Cloud telephony with call recording
- CRM note, field and task write-back
- S3-compatible object storage
- Serverless GPU transcription
- Signed outbound webhooks
- SSO-grade sign-in: passkeys and TOTP
See it summarise one of your own calls.
Send us a single recording and we will show you the transcript, the synopsis, the extracted commitments and the follow-up date it produces — with every claim linked to the moment it was said.
Complete feature guide
Everything the platform does
CallIntell turns recorded phone calls into reviewed, structured records in the CRM, without anyone listening to the call. A recording lands, it is transcribed with speaker labels, personal data is stripped before it reaches a language model, the call is matched to its CRM record, and a synopsis — outcome, commitments, follow-up date — is written back as a note and a scheduled task. Anything the system is unsure about goes to a human queue instead of being guessed. Here is everything it does today.
The pipeline
From a recording to a CRM note, unattended
Six queue-backed stages, each retryable on its own. A call that fails at transcription does not have to be re-fetched, and nothing is written to the CRM twice.
Ingest
- Telephony webhook, with a polling fallback. A call-ended webhook starts the job. Recordings are not always ready the moment a call ends, so a poller sweeps every few minutes and retries with backoff — the webhook is an optimisation, not a dependency.
- Object storage, not local disk. Audio is streamed into S3-compatible object storage on arrival. Workers are stateless and can be replaced mid-run.
- Duplicate detection. A call already in the system is recognised and skipped, so a retried webhook or an overlapping poll cannot produce two synopses or bill twice.
Transcribe
- Speaker-labelled, word-timestamped. A GPU worker runs WhisperX with diarization, so every sentence is attributed to agent or customer and carries a timestamp you can click to hear it.
- Serverless GPU. Transcription runs on serverless GPU capacity rather than a machine that idles between calls — the cost follows the audio minutes.
- Accent handling. Tuned for the mix that actually occurs on these calls: offshore agents speaking to domestic customers, on telephony-grade audio.
Match
- Naming convention first, phone number second. The tenant's own recording-name pattern is parsed to a CRM id. If that fails, the caller's number in E.164 is matched to a contact and their open deal.
- Never guess. An ambiguous or missing match goes to an unmatched queue for a person to link. A synopsis attached to the wrong customer record is worse than no synopsis.
Synopsise
- Per call-type templates. The call type comes from the CRM record, or an AI classifier when the field is empty, and selects the template the synopsis is written into — so sales and support calls produce different, comparable records.
- Structured output, not prose. The model returns a schema-validated object: outcome, next actions, objections, products discussed, price quoted, commitments made. Free text alone cannot be reported on.
- Every point cites its timestamp. Each key point links to the moment in the recording it came from, so a reviewer verifies in seconds instead of re-listening.
Resolve the follow-up date
- "Call me in two days" becomes a dated task. Relative phrases are resolved against the call date and the customer's own time zone, with tenant rules for calendar versus business days and a default time when none was stated.
- The exact words are kept. The verbatim phrase and its timestamp are stored next to the resolved date, so a wrong interpretation is visible rather than silent.
- Vague phrasing is escalated. "Early next week" or "after I speak to my accountant" is flagged for a human rather than turned into a confident date.
Write back
- Note, fields and a scheduled task. The synopsis is written to the CRM record as a note, outcome fields are updated, and a follow-up task is created on the resolved date and assigned to the agent.
- Idempotent writes. Retries cannot duplicate a note or a task. The write is keyed on the call, not on the attempt.
Review app
A reviewer edits; nobody re-listens
The point of the product is to replace listening with checking. Confident results pass straight through; the rest arrive with the evidence already attached.
Call queue
- Only what needs a person. Low-confidence outcomes, dates, prices and commitments route to the review queue. Everything else auto-approves and is written back without human involvement.
- Transcript beside the audio. The speaker-labelled transcript plays in sync with the recording, so a disputed line is one click away.
Ask about this call
- Questions answered from the transcript. A reviewer can ask a question about the call and get an answer grounded in the transcript, with a clickable time for each point rather than a page reference.
Multi-company
- Separate companies in one deployment. Each company has its own calls, users, templates, scorecards and integration credentials. Nothing crosses the boundary.
- Role-based access. Reviewer, manager and administrator roles are configured per company.
Usage and billing
- Minutes tracked per company. Audio minutes are metered as they are processed, visible on a usage page before an invoice is raised.
- Invoices generated in-app. Invoices are produced as PDFs from recorded usage, so the number on the invoice traces to the calls behind it.
Configurable per tenant
- Synopsis templates. Each call type has its own editable template, so the output matches the format the team already uses.
- Scorecards. Quality scorecards are defined per company for scoring conversations against the criteria that matter to them.
Security & privacy
- Personal data is removed from the transcript BEFORE it reaches any language model — a separate redaction pass strips social security numbers, card numbers and bank details, including numbers read aloud in groups that speech recognition writes as digits with pauses.
- Passkeys (WebAuthn) and time-based one-time codes are both supported for sign-in; the review app is not password-only.
- Every action is written to an append-only audit log: who viewed a call, who edited a synopsis, who approved it, what changed.
- Per-company isolation of calls, users, templates and integration credentials.
- Integration credentials are stored encrypted, not in configuration files.
- Recordings live in object storage with pre-signed, expiring URLs rather than public links.
- HTTPS terminated at the edge with automatically renewed certificates.
Reliability
- Six independent queue stages with per-stage retries and exponential backoff — a transient failure in one stage never re-runs the whole pipeline.
- A polling fallback behind the webhook, so a missed or delayed notification does not lose a call.
- Idempotent CRM writes: a retry cannot create a duplicate note or a duplicate follow-up task.
- Unmatched and low-confidence calls queue for a human instead of being written with a guess.
- Nightly database backups.
- An end-to-end test harness that runs the entire pipeline — storage, GPU transcription, CRM and the model — against local stand-ins, so the full path can be exercised with no external accounts or keys.
Ready to Start Your Project?
Let's discuss how we can help you achieve similar results for your business
More Success Stories
Explore our other ai platform projects
DevOps & Infrastructure
ThinClient OS + Fleet Manager
A production-grade Linux appliance that boots straight into a full-screen Windows RDP session — no desktop, no shell, no login prompt — backed by a self-healing watchdog and an infinite reconnect loop. It ships as a reproducible BIOS+UEFI ISO and pairs with a Next.js cloud manager to provision, monitor and remotely control the device fleet.
Read Full Case Study
Data Platform
Database Migration Platform
eSparks IT Solutions built a browser-operated data platform for planning, running, monitoring, and validating real-time migrations between heterogeneous databases. Five relational engines (SQL Server, PostgreSQL, MySQL, Oracle, Db2) migrate in either direction; MongoDB is supported as a CDC source. Its Java 21 and Spring Boot 3 control plane orchestrates jobs, while a React interface supports operation through the browser. For real-time CDC, the data plane uses Debezium, Kafka, and a JDBC sink, with PostgreSQL in the stack and deployment via Docker Compose or Kubernetes (Strimzi). The platform includes end-to-end integrity validation with drift detection, custom Java SMTs, AES-GCM secret encryption, Prometheus/Grafana, and JWT/RBAC security. SQL Server, PostgreSQL, MySQL and MongoDB migrations are live-verified end-to-end — including a production programme that moved roughly 960 million rows across 405 tables from SQL Server to PostgreSQL with zero rows missing at validation; Oracle and Db2 connectors are implemented and tested at the unit/config level, pending live verification.
Read Full Case Study
SaaS
Sparks Business — Inventory, Sales & GST Invoicing Platform
Sparks Business is a multi-tenant platform built by eSparks IT Solutions to run inventory, purchases, sales and GST invoicing from one system. It pairs a NestJS 11 API with an installable Next.js 15 PWA, backed by PostgreSQL 17 through Prisma 6 across 49 data models. Every query is scoped to its tenant through an AsyncLocalStorage-driven Prisma client extension, and an append-only audit table is enforced at the database level — even a direct update or delete against it is rejected by a trigger. GST math (CGST/SGST/IGST splitting, GSTIN validation) runs on decimal.js for exact, rounding-free results, and a real Tally XML importer lets a business bring in existing ledgers, vouchers and stock items instead of starting over. Redis and BullMQ handle background email and document generation, S3-compatible object storage holds product images, invoice PDFs and backups, and Microsoft Graph sends transactional email. Deploys are health-gated, so a broken build never reaches production.
Read Full Case Study