How Do You Build a Proof of Concept Tracker in Airtable?

How do you track a proof of concept so it ends with a decision?

Track it against written success criteria, not against activity. Build a small Airtable base with one table for each proof of concept and one for its criteria, link them, and show progress as criteria met out of criteria agreed. Add dates for the midpoint and decision, and automations that alert the owner when something slips.

Most teams track a proof of concept in a deal record and a few calendar invites. That works until the test runs long, the buyer's owner goes quiet, and nobody can say which criteria have actually been proven. The deal sits in a "POC" stage for months.

A dedicated tracker fixes that by making the agreed outcomes visible every day. This tutorial builds one in Airtable. It pairs with my guide on how to run a proof of concept that ends in a signed deal, which covers the process. This piece covers the system.

What will the finished tracker do?

It will show every active proof of concept with its owner, buyer contacts, dates, and the share of success criteria met. Each criterion will have a threshold, a status, and evidence. Automations will flag criteria as they are met, alert you when the review date is near, and notify the team when a test is ready for its decision meeting.

You will need an Airtable base, a few minutes to set up fields, and somewhere to send alerts, such as email or Slack. Nothing here requires code. If your CRM is HubSpot, you can link each proof of concept back to its deal with the deal ID or URL.

I keep this separate from the CRM on purpose. The CRM is where the deal lives. The tracker is a working document for the test itself, shared with the people running it. It is easier to keep clean when it has one job.

Step 1: How do you set up the Proofs of Concept table?

Create a table called Proofs of Concept with one record per test. Add fields for account name, CRM deal link, internal owner, buyer owner, economic buyer, start date, midpoint review date, end date, and decision date. Add a single select status: planned, running, in review, won, lost, or paused.

The decision date is the field most teams forget. It records when the buyer agreed to make a call, not when the test technically ends. Putting it in the tracker keeps the commercial next step in view for everyone, which is the whole point.

Add a long text field called "What happens if criteria are met." Paste in the exact line from your written plan, such as "contract sent within five business days." It is a small field that keeps the end of the test honest.

Step 2: How do you set up the Success Criteria table?

Create a second table called Success Criteria. Each record is one criterion, linked to its proof of concept. Add fields for the criterion in plain words, the threshold that counts as a pass, a single select status of not started, in progress, met, or not met, an evidence field, and the date it was confirmed.

Keep criteria few. Three or fewer per test is the target I recommend in the process guide, and the tracker makes it obvious when a test has drifted to seven or eight. If you see that, it is a conversation to have with the buyer, not a row count to celebrate.

The evidence field matters. It can be a link to a screenshot, a short note, or an attachment. When a criterion is marked met, there should be something a skeptical finance person could look at. That evidence is what your champion forwards later.

Step 3: How do you show progress on each proof of concept?

Back in the Proofs of Concept table, add a count of linked criteria and a count of criteria marked met, then a formula that shows met out of total. A rollup or count field can do the counting, and a formula field can turn the two numbers into a readable progress line, such as "2 of 3 met."

I also add a formula field that flags risk. For example, if today is past the midpoint review date and fewer than half the criteria are met, show "At risk." This is a simple date comparison and count check, and it turns a quiet stall into something visible on the main view.

Create a grid view filtered to running and in review, sorted by decision date. That is the view your team should open every week. It answers the only questions that matter: which tests are close, which are stuck, and which decisions are coming up.

Step 4: How do you set up the automations?

Use Airtable's "When record matches conditions" trigger for status changes. Its support docs say records that already match will not fire the trigger, the trigger is not retroactive, and a record that stops matching and then matches again runs the automation again. Design around those three behaviors from the start.

The first automation lives on the Success Criteria table. When status becomes met, notify the internal owner with the criterion and its evidence. Because a record that flips back and forth will fire again, add a "notified" checkbox that the automation ticks, and include "notified is unchecked" in the conditions.

The second automation lives on the Proofs of Concept table and handles readiness for review. Airtable's docs warn that conditions spanning more than one field are evaluated as soon as the last one is satisfied, and recommend a dedicated "ready" checkbox for one-time actions. I follow that advice. The owner ticks "ready for decision" when all criteria are met, and that single change sends the alert to book the decision meeting.

A third automation can run on a schedule, such as every Monday morning, and send the owner a summary of their running tests and any marked at risk. It keeps the tracker in front of people without anyone having to remember to open it.

Step 5: How do you share the tracker with the buyer?

Share a filtered view or interface that shows only that buyer's proof of concept and its criteria, with internal notes hidden. Sharing progress openly builds trust and keeps the buyer's owner engaged. It also makes the weekly update easy, because both sides are looking at the same list of criteria and evidence.

Be careful with what is visible. Internal fields such as deal value, risk flags, and notes about the buyer's politics should never appear in a shared view. Create a separate view with only the fields you are happy for the buyer to see, and check it from a logged-out browser before sending the link.

Not every buyer will want a shared tracker. Some prefer a weekly email. That is fine. The tracker still works internally, and you can paste its progress line into the email.

Step 6: How do you connect the tracker to your CRM?

At minimum, store the CRM deal link on each proof of concept record so anyone can jump between them. If you want more, an automation can update a deal property when the tracker status changes, so your pipeline reports reflect which deals are running a test and which are waiting for a decision.

I would start with the link only. Two-way syncing between Airtable and a CRM is useful but adds moving parts. Add it once the tracker has proven itself on a few real tests and the team actually relies on it.

If you are new to building review workflows in Airtable, my tutorial on setting up a manual lead review queue in Airtable covers similar patterns. For larger deals, fold the tracker into your mutual action plan for a mid-market deal.

What should you do next?

Create the two tables, add the fields, and enter one live proof of concept with its criteria. Add the progress and risk formulas, then the three automations, with a notified checkbox and a ready checkbox to keep alerts clean. Share a filtered view with the buyer if they want it, and review the tracker every week.

The tracker is simple on purpose. Its value is not in clever automation. It is in making the agreed outcomes visible every day, so a proof of concept ends in a decision instead of drifting.

If you want help building a tracker like this, or connecting it to your CRM and the rest of your sales process, let's chat. I build systems like this on Airtable, and I am happy to look at what you have.