How recruiting teams stop candidate replies from disappearing with Spoke Phone and Oracle HCM
September 10, 2026
—
4 minutes
Most candidates who reply to a recruiting text expect an answer back, not silence. When that reply goes nowhere, the recruiter loses the conversation and doesn't even know it happened. This guide covers how to close that gap automatically — using Spoke alongside Oracle HCM.
The reply that goes nowhere
Oracle HCM's recruitment module can send a candidate a text message using an optional SMS add-on. What it can't do is bring the candidate's reply back to the recruiter. The message goes out, the candidate responds, and that response simply doesn't arrive anywhere a recruiter would see it.
From the candidate's side, it looks like being ignored. From the recruiter's side, there's no record that a reply ever came in — no notification, no thread, nothing added to the candidate's file in Oracle. The conversation just stops, and the recruiter has no way of knowing whether the candidate went quiet or the system did.
Recruiters end up working around this rather than through it: falling back to email, which is slower and gets fewer responses, or using a separate broadcast SMS tool built for blasting messages to a list, not for one recruiter having a back-and-forth with one candidate.
Why a broadcast tool isn't the fix
A broadcast tool solves a different problem than the one recruiters actually have. It's built to send a lot of messages out, not to let one person carry on a conversation with one candidate inside their normal workflow. Recruiters using one still can't reply to an individual candidate from where they already work, and they still have no way to see that conversation next to the candidate's application status.
There's a second problem sitting underneath the first: consent. A candidate's permission to receive texts is captured during the application and stored in the HR system, but a recruiter sending a message from a separate tool has no way to check that consent before hitting send. And if a candidate texts back "STOP," there's no automatic path for that opt-out to reach the HR system — so a recruiter could keep messaging someone who has already withdrawn consent, without ever knowing it.
What Spoke Phone and Oracle HCM each bring to this
Oracle HCM is where the candidate record lives — application status, contact details, and the consent a candidate gave when they applied. It's the source of truth for who a candidate is and whether they've agreed to be texted, and it's where any change to that consent needs to end up.
Spoke is where the actual text conversation happens. It keeps consent and status in sync with Oracle, checks that a candidate has genuinely opted in before letting a message go out, and gives the recruiter a real, two-way message thread instead of a one-way send. When a candidate replies, it lands in Spoke as a conversation the recruiter can respond to directly. When a candidate opts out mid-conversation, Spoke captures that and writes the change straight back to Oracle.
Neither tool does this alone. Oracle without a two-way messaging layer can log a candidate's consent but can't act as a live conversation channel. Spoke without Oracle would have no reliable record of who's actually agreed to be contacted. Together, the system a recruiter already works in stays in sync with the channel a candidate actually replies on.
What the candidate experiences
A candidate applies for a role and, near the end of the application, is asked whether they're willing to receive text updates. If they say yes, that's recorded immediately — nothing else needs to happen on their end.
Shortly after, they get a text. It comes from a real number tied to their recruiter or team, not a shortcode, and it includes a way to opt out if they change their mind. If they reply, the reply reaches the recruiter directly — not a shared inbox, not a queue, just the conversation continuing.
If the candidate moves forward in the process, the recruiter can keep messaging them from the same thread as things progress. If the candidate replies "STOP" at any point, the messages stop immediately, and nobody accidentally texts them again afterward. Throughout, from the candidate's point of view, it just looks like texting a person back — because that's what's actually happening.
How it applies beyond recruiting
The underlying pattern here isn't specific to hiring. Any team whose CRM or system of record holds a customer's or candidate's messaging consent, and who needs to enforce that consent before a message goes out, runs into the same gap.
Service teams handling inbound requests from customers hit the same wall when a reply needs to route back to the right person rather than a shared queue. Sales teams re-engaging leads who opted in months ago face the same consent question before every outbound text. Any regulated business — healthcare, financial services, insurance — that needs a defensible record of who agreed to be contacted, and who didn't, is solving the same problem this pattern solves.
It's a weaker fit where there's no real HR or CRM system holding consent to sync against, or where message volume is low enough that a recruiter can reasonably check a candidate's status by hand before every send.
"The relationship with the Spoke team has been fantastic. Nothing seems to be off the table from a technical perspective"
Want to implement this for your team?
Get the setup guide and implement Spoke Phone and Oracle HCM working together as one in your recruiting workflow.
