· 6 min read

Escaping the Hiring Tracker Spreadsheet: Building a Lightweight Recruiting Pipeline

Turn a shared hiring spreadsheet into a lightweight recruiting pipeline with clear stages, structured feedback and careful handling of candidate data.

An empty interview room with two chairs and a closed candidate folder.

You have three open roles and one hiring spreadsheet. It has a tab per role, a “Status” column with eleven slightly different spellings of “phone screen”, and interview feedback pasted into a cell so long it scrolls. Last week someone emailed a rejection to a candidate who was about to get an offer, because the row they read was two days out of date.

Worse, the whole thing is shared with forty people, including a few who left the company in spring. That sheet holds names, phone numbers, salary expectations and frank opinions about real people. It deserves better than a link anyone can forward.

Why hiring outgrows the sheet faster than most processes

Hiring has every feature that breaks a spreadsheet at once. Many people touch each record. The work moves through stages with deadlines. Opinions need to stay independent until everyone has given theirs. And the data is personal, so access matters far more than it does for, say, a stationery order.

If you are running a handful of hires a year, a specialist recruiting product may be overkill. A lightweight pipeline built in a no-code database platform or an internal app builder can cover most of what a small or mid-sized team needs, provided you design it deliberately.

Separate the things you are tracking

The spreadsheet’s core mistake is cramming everything into one row. Pull it apart into a few linked record types, as described in From Rows to Records: How to Think About Your Data Like an Application:

  • Roles: the job itself. Title, hiring manager, team, target start date, status (open, on hold, filled).
  • Candidates: the person. Name, contact details, source, and a link to their CV.
  • Applications: one candidate applying for one role. This is where the stage lives. A person who applies for two roles gets two applications, not a duplicate candidate row.
  • Interviews: one scheduled conversation, with interviewer, date and type.
  • Feedback: one interviewer’s assessment of one interview.
  • Offers: salary, start date, approval status, and outcome.

That application record is the one most teams miss. Once it exists, “where is Priya in the process for the analyst role?” has exactly one answer.

Define the stages, and what it takes to move

Replace the free-text status column with a fixed set of stages on the application. A typical pipeline:

StageMoves forward when
AppliedSomeone has reviewed the CV
ScreenRecruiter or manager has a short call and logs a result
InterviewAll scheduled interviews have feedback submitted
DecisionHiring manager records hire or no-hire, with a reason
OfferOffer approved and sent
Hired / Declined / RejectedFinal outcome recorded

Two rules make this work. First, every move to “Rejected” requires a reason from a short picklist (skills gap, salary mismatch, withdrew, role closed). That gives you useful data later and stops people closing candidates without thinking. Second, only certain roles can move an application into Offer. Replacing the “Status” Column: Designing Real Workflows with States and Transitions covers how to set up those rules.

Collect feedback that is actually independent

Pasting feedback into a shared cell has a quiet side effect: the second interviewer reads the first one’s opinion before writing their own. Anchoring is real, and a strong early opinion tends to pull everyone toward it.

Give feedback its own form with a few structured fields: an overall recommendation (strong yes, yes, no, strong no), a score for each competency the role cares about, and a short notes box. Then set the view so interviewers can only see their own feedback until they have submitted it. The hiring manager sees everything once the interview stage closes.

Say you run four interviews per finalist. The debrief now starts with a table of scores rather than a hunt through comments, and disagreements show up immediately.

Handle candidate data like it matters

This is the section to take seriously. Candidate records contain personal information, and some applicants will share things in a CV or cover letter you would never ask for. Rules on how you collect, store and delete this kind of data vary by country and region, so check your obligations with whoever handles legal or privacy questions in your company. What follows is good operational practice, not legal advice.

Restrict access by role. Interviewers need the CV and their own interview. They do not need salary expectations, other candidates’ feedback, or the offer details. A sensible split:

  • Recruiters and the hiring manager: full access to applications for their roles.
  • Interviewers: only the candidates they are interviewing, and only the fields they need.
  • Leadership approvers: offer records, not the full pipeline.
  • Everyone else: nothing. No company-wide link.

Permissions That Make Sense: Who Should See and Edit What goes deeper on role design.

Collect less. Ask only for what you use. If you never look at date of birth or a home address before an offer, do not put those fields on the application form.

Keep CVs in the tool, not in inboxes. Attach files to the candidate record. Every copy in someone’s downloads folder is one you can no longer manage or delete.

Set a retention period and automate it. Decide with your privacy or legal contact how long you keep records for unsuccessful candidates. Then build a scheduled job that flags or anonymises applications that have been closed longer than that period. If you want to keep promising people on file for future roles, ask their permission and record when you asked. Data Retention: How Long to Keep Records and When to Let Go and Privacy Basics for Ops Teams: Handling Personal Data in Internal Tools cover both in more detail.

Keep an audit trail. Make sure your tool logs who viewed or changed a record. You will be glad of it when a candidate asks what you hold about them.

Automate the dull parts, not the human ones

A few automations earn their place:

  • When an application moves to Interview, create the interview records and notify each interviewer with a link.
  • When an interview date passes without feedback, send the interviewer one reminder the next morning.
  • When an offer is approved, notify the recruiter in your chat tool to send it.

Do not let rejection emails fire the moment a stage changes. Have the system draft the message and let a person press send.

Where to start this week

  1. Revoke access to the current hiring sheet for anyone who is not actively hiring. This takes ten minutes and reduces risk immediately.
  2. Write down your stages and the rule for moving between each one, and agree them with your hiring managers.
  3. Ask your legal or privacy contact one question: how long should we keep unsuccessful candidates’ data? Write the answer down.
  4. Build the roles, candidates and applications records for one open role, and run that role’s pipeline in the new tool while the others stay where they are.