Research note
Matching contractors to sales work without a resume
For phone-first sales roles, past employers predict very little. What we look at instead on PlaceMePal, and what we got wrong first.
PlaceMePal places independent contractors into sales work: telecalling, appointment setting, SDR and BDR desks. When we started, we did the obvious thing and built the matching around a profile: past roles, tenure, industries, skills. It is what every job platform does and it is what candidates expect to fill in.
It worked poorly, in a specific and instructive way.
The resume answers the wrong question
For a phone-first sales desk, the thing a client needs to know is whether this person will be effective on calls, starting next week. A resume answers a different question: where has this person been employed. Those correlate much less than the format implies, for reasons that are structural rather than accidental.
- Much relevant experience is informal (family businesses, contract work, freelance desks) and has no employer name to put in a field.
- Tenure at a company measures whether someone stayed, which in this segment is mostly a fact about the company.
- The strongest candidates are frequently career-changers whose prior sector is irrelevant and whose profile therefore looks weakest.
The result was a ranking that systematically preferred candidates who were legible over candidates who were good, and clients could tell.
What we look at now
We moved to signals produced during the process rather than declared before it. The structural change is that the platform generates its own evidence instead of asking candidates to assert things about themselves.
- A short structured call. Ten minutes, same prompts for everyone, scored on a fixed rubric. It is the closest available proxy for the actual job, and it is the single most predictive thing we have.
- Preparation behaviour. Whether someone completed the role-specific preparation before an interview slot. It is a weak signal about ability and a strong one about follow-through, which is most of the job.
- Slot reliability. Whether someone shows up to booked interview slots, on time. Same reasoning, and it is measured rather than claimed.
- Outcome history on the platform. Once someone has completed contracts, this dominates everything else, and it is the only signal that is genuinely about performance.
The cold-start problem is real: a new candidate has none of the fourth signal and the platform has to rank them anyway. We weight the structured call heavily at first and let outcome history take over. Getting that handover wrong in either direction is the difference between a marketplace that is fair to newcomers and one that is not.
What we got wrong first
Our first scoring model treated all four signals as independent contributions and summed them. This produced a ranking where a candidate who never showed up to a slot could still rank well on the strength of a good structured call.
The fix was to stop treating reliability as a score component and start treating it as a gate. Some signals are not "more is better", they are "below this line, nothing else matters". Conflating the two is a modelling error that reads as a fairness problem to everyone on the receiving end of it.
Verification is the boring half
Marketplaces attract fraud, and a contractor marketplace attracts a particular kind: duplicate profiles, borrowed identity for the interview, and no-shows on the first real day. None of this is solved with a better ranking model.
What has worked is unglamorous: identity checked once and bound to the profile, contract documents signed in the flow rather than emailed, and payment protection that gives both sides a reason to keep the transaction on the platform. Push the transaction off-platform and every signal above stops being generated, which is a data problem long before it is a revenue problem.
Still open
The structured call is our best signal and it is expensive: ten minutes of someone's time per candidate, and a rubric that needs periodic recalibration to stay honest. Whether a shorter or asynchronous version retains enough of the signal is something we are actively testing and cannot yet answer.