A recruiting team at Hims & Hers now pulls hiring-pipeline status from a Slack command instead of assembling it by hand, according to a first-person account published by Zapier. Carlos Robledo, a Lead Technical Sourcer at the company, built a system he calls Rex: a set of 19 workflows that connects the applicant tracking system Ashby to Airtable and Slack, and that is now used by recruiters across the organization.
Rather than emerging from a top-down product decision, this account traces a specific origin point. Two major updates, spanning several open requisitions, fell to Robledo while he supported his Chief Product Officer; assembling a picture of where candidates stood meant moving among the applicant tracking system, Slack and other tools. At that time he carried more than 15 requisitions, some teammates carried 20 to 25, and per the source, candidate updates, interview changes, stale applications and offer activity could fall through the cracks.
Robledo's first move was to check whether Ashby exposed the data he needed, then use Zapier to route it into the tools the recruiting team already used. The initial version of Rex focused on reporting, pulling recruiting information into Airtable and Slack so he could monitor active requisitions and share updates with hiring teams. The source frames this as the beginning of a pattern: each later feature grew out of a friction point teammates actually raised.
Concrete is the documented feature list. Coverage under Rex expanded to include monitoring of stale candidates, updates when interviews are created or cancelled, notifications upon offer acceptance, pipeline reports, referral and inbound applicant workflows, plus alerts for candidates sitting outside service-level expectations. Each of these, the source says, ties back to a request — a recruiter wanting to be kept current on interview changes, to be told who has been sitting too long, or to be warned when a candidate is outside SLA, for instance.
The most significant design change was moving from scheduled delivery to on-demand answers. Rex initially delivered reports at a fixed time, but Robledo concluded that a fixed schedule still reflected his own assumption about when people needed the information. He built a Slack interface so recruiters could type /rex and request pipeline information when they needed it, receiving a structured response formatted for quick reading and action. The source says this shifted Rex from a reporting workflow into an internal recruiting tool.
Adoption was driven by a step-by-step rollout. Robledo's first move was to work with the people closest to him, asking what would actually make their work easier, building to those requests, and then bringing back functioning iterations so users could try them — which exposed defects and made clear which capabilities were essential. Once the tool had grown more capable, his manager brought it before recruiting leadership, including the VP of Recruiting along with the SVP of HR and People. Leadership then extended an invitation, and Robledo presented the system to roughly 60 to 70 individuals throughout the wider People function, showing them the way a position gets enrolled, the format of a weekly report, and how Rex could deliver information with no additional manual data pull.
A comparison that shaped the design is also documented by the source. An internal bot connected directly to Ashby through MCP was one of Robledo's experiments. Retrieving recruiting information and offering better access control were things that bot could do, yet the structured Slack experience he had built could not be reproduced by it, and its output proved less predictable and harder to scan. The account presents this as evidence that a better employee experience does not automatically follow from more direct AI access.
Deliberately mixed is the architecture described. Orchestration falls to Zapier, recruiting data comes from Ashby, Airtable stores and organizes information, and the interface is provided by Slack. Two places use AI: helping build and improve the system, and at the edges where interpretation helps — for instance, making sense of a plain-language /rex request and converting raw stage data into a readable briefing instead of a table dump. The machinery runs the same way every time, the source states, and this repeatability is what makes recruiters trust it.
The scale figure rests on arithmetic, not on a formal measured study. Per the source, manually reading and compiling a single role's pipeline consumes roughly 20 minutes; multiplied across about 143 open requisitions and performed weekly, that totals approximately 2,860 minutes — close to 50 recruiter-hours every week devoted to assembling status before anyone has looked for stalls, pursued feedback or responded to a stakeholder question. Robledo puts the system's recovery at as much as 50 recruiter-hours per week, and the source credits that number to his estimate, not to any independent measurement.
The account makes explicit that this is a composable system, not a locked product — which is why a snag a recruiter hits can turn into a Rex behavior. As Robledo describes the process: begin with a concrete problem, check whether the underlying systems can support a fix, construct a small version, and then refine it alongside real users. According to the source, what emerges is a recruiting workflow available to people whenever a candidate's status changes, a role requires attention, or a hiring manager needs an answer.
For freelancers, designers and developers, the transferable element is the pattern rather than the recruiting domain. A recurring manual report that one person rebuilds on a schedule is a candidate for a small internal tool, and the source's account suggests the useful first step is checking whether the existing systems already expose the needed data before building anything. The second transferable element is the interface choice: the same data delivered as an on-demand command in a tool people already use was adopted more readily than a scheduled report, according to the account.
There is also a caution embedded in the bot comparison. The source does not claim that a direct AI connection to a data source is worse in general; it describes one internal bot that had better access control but produced less predictable, harder-to-scan output than the structured Slack experience. For anyone weighing an AI assistant against a deterministic workflow, that is a single documented case, not a general rule.
The limitations of the evidence matter here. This is a first-person account published by Zapier, a vendor whose product is central to the system described, and it is not an independent evaluation. The 50 recruiter-hours figure is Robledo's estimate, and the underlying 20-minute-per-role and 143-requisition numbers are the source's own arithmetic rather than a timed study. No pricing, licensing or availability details for Rex are given, and the source does not say whether the system is offered outside Hims & Hers or how it is maintained.
The source also does not describe failure modes, error rates or what happens when the underlying data in Ashby is wrong or incomplete. It does not quantify adoption beyond the 60-to-70-person demonstration and the statement that the system now supports recruiters across the organization. The claim that the machinery runs identically every time is a description of intent and design, not a verified reliability measurement.
What the account does establish is a documented sequence: a recurring manual reporting task, a builder who checked his data source's capabilities, a small first version, iterative testing with the people who felt the problem, a shift from scheduled to on-demand delivery, and a staged rollout from a single team to a broader function. That sequence is the substance of the story, and it is reproducible in outline even where the specific tooling is not.
The unresolved question is whether the recovered time translates into different work or simply more requisitions per recruiter. The source does not address that, and it does not report whether the system changed hiring outcomes. Those gaps are worth keeping in view when reading the 50-hour estimate as a productivity claim rather than a measured result.