In short. An online form feeding a spreadsheet is a sensible way to start a selection programme, and for a small call it is often enough. It breaks at a predictable point: when there are enough applications, enough reviewers or enough decisions that the spreadsheet has to do jobs it was never built for. Those jobs are catching duplicates, keeping versions straight, hiding identity from reviewers, recording who did what, and sending the right letter to the right person. Move to a selection system when two or more of those start costing you real hours.
This is not an argument against forms or spreadsheets. Both are excellent tools. A form is the quickest way to ask the same questions of everyone, and a spreadsheet is the quickest way to look at the answers. The trouble starts when a programme asks the pair to behave like a workflow.
What the Form-and-Spreadsheet Setup Does Well
It is worth being fair about this, because the setup survives for good reasons:
- Zero cost and zero training. Everyone on the committee already knows how to open a sheet.
- Total flexibility. An extra column, a colour code or a pivot table takes a minute.
- Transparency to the person who built it. They know every formula.
- A low barrier for applicants. A simple form asks little of them.
For a call with perhaps 30 applications, three reviewers who sit in the same room, and one decision meeting, this is a sound choice. Nothing here needs fixing.
Where It Breaks
The failures are consistent across programmes. They arrive roughly in this order as a call grows.
Duplicates
Applicants submit twice. A form times out, a co-applicant does not know their teammate has applied, or someone fixes a typo by starting again. The spreadsheet shows two rows, usually with slightly different details, and nothing says which one stands. Reviewers end up scoring both, or one reviewer scores one and another scores the other. Cleaning this by hand means reading each pair and deciding, and the decision is rarely written down.
Versions
A sheet is shared, copied, downloaded, sorted and re-uploaded. By the second week there is "Scores_final", "Scores_final_v2" and "Scores_final_v2_Meena". A reviewer who sorts one column without selecting the others silently misaligns every row below it. None of this is visible until a team asks why its score is different from the one it was told.
Blind Review
A blind review needs the reviewer to see the work but not the person. In a spreadsheet, that means hiding columns, and hidden columns are not protected. They can be unhidden, copied and filtered. File names, pasted answers and attached documents carry names too. Anonymity that depends on every reviewer's good habits is hard to promise to applicants and harder to show later.
Conflicts and Assignment
Who reviews what is a matching problem: expertise, workload and conflicts all matter. In a sheet it becomes a manual list. A conflict (a reviewer who co-authored with an applicant, or sits on their board) is remembered by the one person who knows about it, and if that person is away, the assignment goes ahead.
Audit
When a dispute comes, the questions are simple. Who changed this score? When? What was the score before? A spreadsheet's version history can answer some of this if someone knows where to look, but it was not designed to record decisions as decisions. For funders and public bodies, being unable to reconstruct how an outcome was reached is itself a risk.
Letters
The last mile is the most error-prone. Mail merge from a spreadsheet works until a row is out of order, a waitlist number is typed by hand, or the "accepted" template goes to a person who was declined. A mistake at this step is the one applicants remember.
A Quick Test: Is It Time to Move?
Score yourself against these questions. Each "yes" is a sign the setup is working against you.
Two or three yeses is the threshold at which many programmes start losing time. Five or more usually means the spreadsheet is already the main source of problems.
What a Selection System Must Do
If you are evaluating a replacement, whether built in-house or bought, here is a requirements list you can use as a checklist. It applies to any product, not only ours.
- Intake. Configurable forms, file uploads, deadlines, optional late grace, and a way for applicants to return to a draft.
- Duplicate and resubmission handling. Detect likely duplicates, show them side by side, and record which record stands and why.
- Eligibility checks. Apply published rules the same way to every application, and record the result.
- Rubrics and scoring. Scored criteria with descriptors, weights, and a way to correct for strict and generous reviewers.
- Assignment. Match reviewers to applications by expertise and load, with conflicts excluded.
- Blind review. Hide identity in every place it appears, including written answers and documents, and not only in a column.
- Roles and permissions. Reviewers see their own assignments, committee members see what the committee needs, and applicants see only their own records.
- Decisions. Record outcomes, including waitlists with rank, and keep dissent visible.
- Letters. Templates with fields filled from the record, a test send, and a log of what went to whom.
- Audit. A record of who did what and when, which cannot be edited by the person it concerns.
- Data export. Your data should leave as easily as it came in.
- Privacy. Sensitive answers restricted to those who need them, and a deletion route for personal data.
A tool that does six of these well may be better for you than one that promises all twelve. Rank them by what has hurt you before.
Migrating Without Losing a Cycle
The biggest fear is disruption. Reduce it with a plan:
- Move at the start of a call, not the middle. Never switch systems after applications have opened.
- Run one real call, small, first. A fellowship round of 40 teaches more than a demo.
- Import history deliberately. Past applicants, decisions and scores can be brought in as reference, so that returning applicants are recognised.
- Keep the spreadsheet as a read-only archive for one cycle, then retire it.
- Write down your rules first. Eligibility, conflict windows, tie-breaks and letter wording are decisions, and moving them into software is the moment to make them explicit.
Where IdeaScore Fits
IdeaScore is built to take over the jobs listed above while leaving the parts of the spreadsheet that people liked. Intake, duplicate flags with side-by-side comparison, scoring against a rubric, conflict-aware assignment, blind review that holds, decisions, letters with a test send and an audit log all sit in one place. Names and contact details are never sent to IdeaScore AI, and applicants are told when IdeaScore AI helped.
The spreadsheet does not disappear. Teams can still be brought in from an Excel or CSV file, and results can be exported to a sheet when a trustee or auditor wants one. The aim is to make the sheet an output rather than the system of record.
Questions Programme Officers Ask
Can we keep using our form tool? Often yes, where the tool can send responses to the selection system. The test is whether duplicates, drafts and attachments survive the journey.
Is a spreadsheet ever the right choice for blind review? For a very small committee that trusts each other and has no external audit, it can be. Any promise of anonymity to applicants calls for something sturdier.
How long does a move take? Plan for a few weeks of preparation before a call opens, most of it spent on writing down rules, not on software.
What if our process is unusual? Unusual is fine. Write it down. If it can be written down clearly, a system can follow it.
