Roadshow's Airtable pipeline gave the team shared visibility. Recruiters could see applicants, events, and pipeline stages in one place.

But visibility was not the same as workflow confidence.

Recruiters still had to send emails, watch for responses, coordinate interview times, check documents, request references, update statuses, and leave enough notes for someone else to understand what had happened. The pipeline showed where an applicant sat, but it did not reliably show what decision needed to happen next.

Cleaning up Airtable would have improved the surface. It would not have changed the operating model. The useful improvements depended on more seats, premium integrations, connector tools, and manual administration, especially for a business that would need to bring contract recruiters on and off the system.

I ran recorded, transcribed discovery sessions with Roadshow's founder, manager, and recruiter. We walked through the live Airtable setup, traced the recruiting process from application to offer, and identified where recruiters relied on memory, shorthand, manual follow-up, or side-channel communication.

The team had already created workarounds that showed what the system needed to understand.

Instead of asking recruiters to move applicants through statuses, rssHQ asks recruiters to make the next decision.

A status still exists, but it is not the main interaction. It is the result of something meaningful happening: an invite was sent, an interview was scheduled, notes were added, an offer went out, a candidate was placed on Hold, or someone was kept Warm for later.

That reframed the applicant profile as the recruiting command center. A recruiter or manager should be able to open one profile and understand where the applicant is, what already happened, what is blocking progress, what action is available next, whether required documents and references are complete, and why someone was paused, moved forward, or manually overridden.

In Airtable, status was doing too much. It told the team where someone might be in the pipeline, but the recruiter still had to interpret what that meant and decide what to do next.

Someone could be "interviewing," but that might mean the invite was sent, the interview was scheduled, notes were missing, or a recommendation was ready. The only way to know was to open the record and reconstruct the history.

I designed the applicant detail view around contextual actions instead of a generic status menu. When an applicant is ready for the next business decision, the system asks the recruiter what should happen next. In a Recommended state, for example, the available actions are not abstract statuses. They are choices: Send Offer, Warm, Hold, or Pass.

Before rssHQ, inviting someone to interview required a manual cascade: decide the applicant should move forward, draft or find the right message, send the email, watch for a response, coordinate a time, add the interview to a calendar, and return to Airtable to update the record.

Every step depended on the recruiter remembering to do the next one. Every manual handoff created a chance for the applicant to stall.

I designed rssHQ so the recruiter's decision starts the workflow. When a recruiter takes an action, the system can send the right communication, open scheduling, update applicant state, and record activity history. The recruiter does not have to separately maintain the status after doing the work somewhere else.

As a designer with implementation fluency, I used AI-assisted development to turn the workflow model into production behavior: branded emails, applicant-specific links, internal scheduling, NDA/reference gates, and activity history. That reduced Roadshow's dependence on Airtable seats, premium integrations, connector tools, and a larger vendor-heavy build before the team could test the product in production.

The applicant profile could not become a reliable source of truth if the most important steps happened somewhere else.

Applications, NDAs, references, interview scheduling, email reminders, and event-specific links all happen outside the recruiter's immediate view. If those steps stayed disconnected, rssHQ would recreate the same problem Airtable had: important context spread across tools, tabs, and memory.

I built applicant-specific and event-specific flows so external actions returned to one profile. The applicant profile became the place where outside steps returned and became visible.

Roadshow's workflow had real requirements. Applicants should not be interviewed before signing the NDA. They should not receive an offer before providing the required references.

But real operations always have exceptions. Someone may sign outside the system. A recruiter may need to recover from an edge case. A manager may need to move someone forward for a valid reason.

I designed gates with accountable escape hatches. If an NDA is missing, rssHQ makes the blocker visible and gives the recruiter a direct reminder action. If an applicant has not met the reference requirement, the offer path stays blocked until the requirement is satisfied.

Not every applicant needed an immediate yes/no decision. Some were promising but unavailable, better for a future event, or worth keeping close as backup.

I separated active progress from longer-term continuity. Warm preserved future or backup candidates without cluttering active review. Hold paused someone for a known reason, with the reason attached to the applicant record.

That kept the active queue clearer without losing people Roadshow might need later.

rssHQ is in production testing before broader rollout. The flows shown here are working product behavior, not speculative mockups.

The clearest workflow reduction is the interview invite flow: what previously required seven manual steps across email, scheduling, calendar coordination, and record updates now begins with one contextual action.

The deeper outcome is workflow confidence. Recruiters have more confidence about where applicants are in the process because status, blockers, documents, references, scheduling, notes, and next actions live in one applicant-centered workflow.

Because rollout is still early, I am not claiming scaled adoption metrics yet. The strongest evidence is the shipped workflow behavior: rssHQ reduces manual coordination, makes applicant state easier to trust, and gives recruiters and managers one place to understand each candidate's path through the process.

The work did not disappear. It became visible, sequenced, and easier for the team to trust.

When a team overloads names, notes, statuses, and side-channel follow-up, the answer is rarely just cleaner taxonomy. It is usually a sign that the product is missing the real unit of work.

For rssHQ, the real unit was the recruiter's decision and everything the system needed to carry after it: the next step, the blocker, the exception, the reason, and the record someone else could trust later.

A workflow system should not just describe progress. It should make the next responsible decision clear.