In this eight-bucket split of 5,519,394 type-labeled captured conversations, 68,507 carry a debrief label, or 1.24%. The debrief bucket ranks fifth, with three buckets below it.
The unclassified bucket holds 7.46% of the same split, 6.01 times the size of the debrief bucket. The classifier assigned those conversations to the unclassified bucket, which is one of the eight rows in the partition.
These figures describe the capture record. A label share drawn from that record cannot account for conversations outside it.
What the type split holds
The eight counts add to the full split, and their shares add to 100.00%, so this isn’t a filtered selection. The classifier assigns each conversation to one row.
| Conversation type | Captured conversations | Share of the split |
|---|---|---|
| candidate_interview_generic | 4,750,121 | 86.06% |
| unclassified | 411,636 | 7.46% |
| intake | 127,841 | 2.32% |
| non_interview_business | 88,569 | 1.60% |
| debrief | 68,507 | 1.24% |
| reference_check | 34,765 | 0.63% |
| technical | 30,144 | 0.55% |
| recruiter_screen | 7,811 | 0.14% |
About the data. The table is based on an all-time snapshot of 5,519,394 aggregated and anonymized type-labeled conversations captured on Metaview.
Most of the split sits in candidate_interview_generic: 4,750,121 conversations, or 86.06%, and that label doesn’t identify a stage.
Intake is the largest explicitly named hiring stage. The intake calls guide covers how to run intake meetings. The intake row counts only conversations assigned the intake label. The named non_interview_business bucket sits outside the hiring stages, while the generic and unclassified buckets don’t identify one.
What a debrief label can and cannot tell you
The debrief row’s label is classifier-detected rather than ATS-confirmed. The recruiter-screen row shares that limitation, so this analysis doesn’t classify recruiter screens cleanly. Only 7,811 captured conversations carry a recruiter-screen label, 0.14% of the split. This finding agrees with the caveat already published in the recruiter phone-screen article.
"Teams barely debrief" is unsupported. The debrief share comes from labels in the capture record. That record can’t include a conversation when no recording bot was present, and the classifier doesn’t confirm type against an ATS. Together, those limits leave the data without a complete numerator or denominator for measuring how often hiring processes include a debrief.
Every bucket belongs to the same denominator. The numerator includes only conversations carrying the debrief label, while the denominator doesn’t count hiring processes, candidates, roles, or decision meetings.
A debrief label is not the same unit as a decision meeting: one is a classifier output on a captured conversation, while the other is an event in a hiring process.
A stage-label count belongs to the query that produced it. For a role-level view of the capture record, see Metaview’s time-to-hire-by-role analysis. Because that analysis draws on a different sample, its stage counts aren’t comparable with this table’s. The counts in this article come from the eight-bucket analysis of 5,519,394 type-labeled captured conversations.
The same boundary appears in Metaview’s analysis of debrief influence: captured volume cannot tell us who shaped a decision or whether anyone changed their mind.
The labeled share sets the floor
Of the 5,519,394 type-labeled captured conversations, 411,636 are in the unclassified bucket, or 7.46% of the split. That bucket is 6.01 times the size of the debrief bucket.
The unclassified row does not identify a conversation type, so the table cannot tell whether any of its conversations belong in the debrief bucket. The true share of debrief conversations could be higher than the labeled share reported here, but this analysis cannot quantify the difference because it does not measure the classifier’s accuracy.
A conversation with no recording bot produces no row, and the record contains no count of those absent conversations. The observed labels can support a floor but cannot support a behavioral estimate that needs a complete numerator and denominator.
The debrief row gives you a reason to inspect your own decision records. That inspection starts with a denominator you can define in your own systems.
What to change on Monday
Define the artifact test before you count. A decision event passes the durable artifact test when you can retrieve a written record of what the meeting discussed or decided.
- Use ATS stage names and calendar titles to list the decision events in scope.
- Deduplicate events that appear in both sources.
- Apply the same pass-or-fail test to every identified event.
- Use all identified decision events as the denominator and events that pass as the numerator.
- Calculate the share from those two counts.
The result is artifact coverage among identified decision events. ATS stages and calendar titles can miss events, so the result does not establish coverage across every decision meeting.
For meeting practice, read Metaview’s articles on effective interview debriefs and wash-up meetings.
Where consent is given, the Notetaker captures every spoken word. It turns the recording into a transcript and structured notes, so the hiring team can review what was said after the conversation.
Where Metaview fits
Metaview is the Agentic Recruiting Platform, and the Notetaker is one of its agents. It works on interviews and debriefs.
- 1Each captured call carries a type label in the Type column.
- 2Duration and interviewer details sit beside each call.
- 3The ATS column shows sync status for each call.
Metaview’s candidate-facing copy says, "If both you and the interviewer consent, you will see a ‘Metaview Notetaker’ appear as a participant during the interview." The buyer owns the consent process under its policy and local law, and Metaview does not obtain or guarantee consent.
Several conversations and documents can combine into one synthesized notes document. For intake and debrief notes, Metaview captures the evidence. People still make the decision, and Metaview never auto-rejects a candidate or decides who advances.
Treating the debrief share as proof that "teams barely debrief" would turn a record limitation into a diagnosis of meeting behavior. That diagnosis could send you to review how your meetings run before checking whether your own decision records are complete. The analysis can’t tell whether either problem exists in your process.
On Monday, retrieve the written artifact for every decision event in scope and flag each event that lacks a durable record. That audit shows where the team’s evidence trail needs repair.
Capture what your debriefs leave behind.
See how Metaview’s Notetaker creates structured notes from interviews and debriefs.
Frequently asked questions
Does the split show a trend over time?
The split is one all-time snapshot, so it can’t show whether any bucket has grown or shrunk. You can compare buckets within that snapshot, but you can’t turn those differences into a trend.
Which hiring-stage buckets are explicitly named in the split?
The explicitly named hiring-stage rows are intake at 127,841, debrief at 68,507, reference check at 34,765, technical at 30,144, and recruiter screen at 7,811. The table reports them separately and doesn’t combine them into a new total. The base for each count is 5,519,394 type-labeled captured conversations.
What does the generic candidate-interview bucket mean for stage analysis?
The generic label tells you it’s a candidate interview, but it doesn’t identify the stage. You can’t redistribute those conversations among intake, recruiter-screen, technical, debrief, or reference-check rows from this analysis.
Why can’t a share of the capture record become a percentage of hiring processes?
The two denominators don’t count the same thing. The capture-record share divides a classifier-detected label by captured conversations. A hiring-process percentage would need a count of processes and a complete record showing whether each one included a debrief, and this analysis has neither.
