Score Fillout applications as a committee, not in spreadsheets

I want an app my review committee works out of instead of a shared spreadsheet, for scoring inbound applications collected on a Fillout form. Use Fillout List Forms so I can pick which form holds the applications, and Fillout List Form Submissions to pull the applications themselves. The important constraint to design around: Fillout submissions are read only and there is no update submission operation, so every score, note, decision, and agent brief has to live in a Fillout Zite table keyed by submission id, written with Create Record and Update Record and read back with List Records.

Set up three Zite tables. An applications table with one row per submission id holding applicant name, applicant email, organization, review status, decision, decision notes, who decided, when they decided, whether the outcome email has been sent, and the research brief with its status and last updated time. A scores table with one row per submission id plus reviewer email, holding the score for each rubric criterion, the weighted total, per criterion notes, an overall comment, and the time it was submitted. A criteria table holding the rubric itself: criterion name, description, weight, maximum score, and sort order, so the rubric is configurable inside the app rather than hard coded. Keep the criteria wording generic, because this same app should suit grant, scholarship, job, vendor, and speaker review equally.

The main screen is a review queue. Pull the applications with List Form Submissions, finished responses only, paging through until you have them all, then read the scores table with List Records and join on submission id so you can tell what the signed in reviewer has already done. Default the queue to My queue, meaning applications this reviewer has not scored yet, with tabs for all applications, ones I have scored, and ones already decided. Each row shows applicant name, organization, submitted date, how many reviewers have scored it so far, the current average score, and the decision status.

Opening an application shows a two column detail page, applicant materials on the left and the scorecard on the right, so a reviewer reads and scores without switching screens. Fetch the full answers with Get Submission by ID and render every question and answer in the order the form asks them, with file uploads shown as links. On the right, render the rubric from the criteria table as one row per criterion with a score control and a notes box, plus an overall comment field, and show the running weighted total as they score.

Saving writes to the scores table: Create Record the first time this reviewer scores this application, Update Record if their row already exists, so a reviewer can revise their own scores but never overwrite anyone else's. Hold back other reviewers' scores and notes until the current reviewer has submitted their own, so nobody anchors on what a colleague already gave, then reveal the full comparison immediately after they submit.

Put a Research this applicant button on the detail page that kicks off a background agent. The agent looks up the applicant and their organization on the web, then writes a short due diligence brief covering what the organization does, its size and stage, anything notable or concerning, and links to its sources, saving it back onto that application's row with Update Record along with a status and timestamp. The detail page shows the brief inline once it lands, with a running state while the agent works and the date it was written so reviewers know how fresh it is. Make clear in the interface that the brief is research assistance and not a score.

A leaderboard page ranks applications by average score across all reviewers, built from the scores table with List Records. Show the average, the number of reviewers who have scored, the spread between the highest and lowest reviewer, and the per criterion averages. Flag disagreements where that spread crosses a configurable threshold so the chair can pull them into discussion, and show reviewer progress so it is obvious who still has applications waiting on them.

A decision panel on the detail page lets the chair mark accept or reject with a rationale, saved to the applications table with Update Record along with who decided and when. Once a decision is recorded, the chair can send the outcome email through Gmail Send a Message, using an accept or reject template that fills in the applicant name and a committee summary drawn from the reviewers' notes. Always show the filled in email for review before it sends, record the sent timestamp on the row, and never send twice for the same application.

Identify the reviewer by the signed in viewer's email address and use that anywhere per reviewer behavior is needed. Keep a configurable list of chair email addresses; everyone can see the decision panel but only a chair can act on it, and the controls are disabled rather than hidden for everyone else. Add a settings screen for picking the form, editing rubric criteria and weights, setting the disagreement threshold, editing the two email templates, and managing who chairs.