Turning Interview Transcripts into Candidate Records
Consultants at a London executive search firm ran registration interviews over video. Everything a candidate said about salary, notice period and location was transcribed automatically, then sat in a document nobody opened again. This is how those transcripts became structured candidate records, without a single blank ever overwriting a value a consultant typed.
The Challenge: A properly interviewed database that showed none of it
The firm, an executive search business in London with around fifteen staff running JobScience on Salesforce, interviewed every candidate properly. Salary expectation, notice period, location, what they were actually looking for: all of it was said out loud, transcribed automatically, and then sat in a document nobody opened again. Writing it up afterwards took twenty minutes to half an hour, and at the end of a day with four interviews in it, that write-up did not always happen.
The result was a database of candidates who had all been interviewed and whose records showed almost none of it.
Three things made this harder than it looks. JobScience is built on Salesforce but keeps candidates and applications in custom objects, so the usual Salesforce connectors do not reach them. The transcript arrived as a multi-tab Google Doc with meeting notes on one tab and the transcript on another, and the two needed handling differently. Most importantly, candidate records already contained good information entered by hand, and a system that overwrote a real salary figure with a blank because the model could not find one in the transcript would have been worse than no system at all.
What Was Built: A pipeline with a gate on every write
A pipeline triggered by the transcript arriving by email. It pulls the document, separates the notes from the transcript, and runs two extraction passes: one producing structured fields, one producing readable interview notes. It identifies the consultant by looking them up in Salesforce, then matches the candidate in order of certainty: on a direct record link when the consultant supplies one in the share, on email address next, and on name and recency as a last resort. Where more than one record matches, it flags to the consultant rather than guessing.
Before anything is written, an existing-data check runs against the record. Populated fields are protected. Blanks do not overwrite. What does get written is confirmed back to the consultant in an email showing exactly which fields changed, so a wrong value gets corrected in the next sixty seconds rather than surfacing months later in front of a client. From sharing the transcript to an updated record is typically under five minutes.
Registration interviews now produce structured candidate records and readable interview notes as a matter of course, and the write-up stopped competing with the next interview for the consultant's time.
20+ CRM fields written per call - sixteen AI-extracted data points plus the system fields, alongside a structured interview write-up appended to the record.
Around fifteen minutes of admin removed per interview. The manual write-up took twenty minutes to half an hour when it happened; the automation replaces it with a minute of checking a confirmation email. Fifteen is the conservative end.
Roughly 360 hours of consultant time freed a year on a basis of thirty recorded interviews a week - before counting the interviews that previously produced no write-up at all.
The AI cost of processing a full interview is a few pence.
Worth noting: the confirmation email was not in the original brief, and it is the part the consultants mention. Automation that writes to a candidate record silently gets distrusted quickly, and once it is distrusted people go back to checking everything by hand, at which point you have paid for a system and kept the work.
The client is anonymised because this work touches candidate data and internal process. The technical detail is accurate; the time figures are stated estimates on the basis given rather than measured values.