A won deal can still arrive at customer success with missing setup details, unclear promises, and no obvious next owner. An Airtable customer onboarding checklist can turn that handoff into a small, reviewable package: what sales agreed, what the customer still needs to supply, and which internal tasks are ready to begin.

Use miniExtensions to give the customer a focused portal for supplying their part. Keep the sales handoff and internal setup review in Airtable. The goal is a deliberate Handoff Complete decision, supported by actual prerequisites, rather than assuming that changing a deal to Won starts a ready-to-run implementation.

Before inviting end users, confirm a suitable paid plan or active trial for sharing, and check the workspace-wide child-form allowance for this setup.

Start at the point where ownership changes

Imagine a fictional reporting service, Harbor Metrics, onboarding a new customer, Northline Studio. Sales representative Alex has agreed a standard reporting setup. Customer success owner Priya needs the customer’s reporting goals, a nominated operational contact, and a harmless sample of the report layout they want.

The customer contact, Jo, can provide those inputs but should not see sales negotiation notes or edit the team’s implementation decisions. A delivery specialist needs enough accepted information to configure a demonstration workspace. Priya owns the decision that sales has handed over a usable account.

Write a short handoff definition before building: the sold scope has been checked, a customer success owner has accepted responsibility, required customer information has been reviewed, and the initial setup tasks have named owners. Later rollout milestones can continue after this handoff; completing the checklist does not mean the whole customer implementation is finished.

Keep the account, handoff, and inputs connected

The following suggested records make the ownership change visible. If you already use the Airtable CRM and sales pipeline model, retain its account and deal records rather than copying the same customer into a second unrelated list.

  • Accounts: Account Name as primary single-line text and Account Reference as text.
  • Customer Contacts: Name as primary text, Email as an email field, and Account as a single link to Accounts. This is the customer portal’s users table.
  • Owners: Owner Name as primary text, Team as a single select, and Work Email as an email field. Use this for internal task ownership.
  • Onboarding Cases: Case Reference as primary text, Account as a single link, Won Deal as a link to the existing Deals table, Sales Owner and Success Owner as separate links to Owners, Agreed Scope and Handoff Questions as long text, and Target Start as a date.
  • Case decisions: Scope Checked as a checkbox, Ownership Accepted as a checkbox, Handoff State as a single select: Preparing, Missing Prerequisite, Ready for Review, Handoff Complete; Reviewed By as a link to Owners; and Reviewed On as a date.
  • Setup Tasks: Task Name as primary text, Onboarding Case and Owner as single links, Due Date as a date, Instructions and Completion Evidence as long text, Progress as a single select: Not Started, In Progress, Blocked, Reported Complete; and Required for Handoff as a checkbox.
  • Customer Inputs: Input Name as primary text, Onboarding Case as a single link, Responsible Contact as a direct link to Customer Contacts, Instructions and Response as long text, Sample File as an attachment, Customer Ready as a checkbox, Review Status as a single select: Awaiting Response, Reviewing, Needs Clarification, Accepted; and Customer Feedback as long text.
  • Prerequisites: On Setup Tasks, add Required Inputs as a link allowing multiple Customer Inputs, plus Dependency Review as a single select: Not Checked, Blocked, Ready. Priya maintains this review field.

Create case NL-01. Add three input rows: Reporting Goals, Operational Contact, and Example Report Layout, all assigned to Jo. Add tasks “Check sold scope” for Alex, “Review customer inputs” for Priya, and “Prepare demonstration workspace” for the delivery specialist. Link the last task to the goals and layout inputs through Required Inputs.

Ask the customer only for the missing information

Priya should read the sales handoff first. If the agreed reporting goal is already recorded clearly, prefill a concise statement for Jo to confirm or correct rather than asking them to repeat the entire sales conversation. Keep sales assumptions labeled until the responsible person confirms them.

Create a miniExtensions Portal with Customer Inputs as its data table and Responsible Contact as the users relationship. The login guide explains the direct relationship between a user and their multiple records. Do not rely on the indirect path through case and account.

Show Input Name, Instructions, Review Status, and Customer Feedback as context. Allow Jo to edit Response, Sample File, and Customer Ready. Keep the case link, contact assignment, and reviewer fields out of customer control. Disable input creation so the customer completes the prepared checklist rather than creating parallel rows with unclear ownership.

In Users & Login → Login Fields, enable Two-Factor Authentication (Email verification) for the Email field. Each customer contact needs one valid address. For every private view, choose Personal records only (linked to the logged in user) under Filter and Sort.

Keep Accounts, Deals, Owners, and internal Setup Tasks outside this customer portal. Display only the context needed to answer a request, without expandable links to the underlying sales records. Provide Action Needed and Received views, and verify that both retain personal-record scope.

Review prerequisites before starting dependent work

Jo supplies the goals and layout sample but leaves the operational contact unanswered. Priya reviews the two completed inputs and records Accepted. Customer Ready is a handoff signal; it does not replace that review. A file can be present but unreadable or irrelevant.

The demonstration task depends on the accepted goals and layout. Priya can mark Dependency Review Ready for that task while the operational-contact input remains outstanding. The case itself stays Missing Prerequisite if the contact is required for the agreed handoff.

This distinction prevents two common problems. One missing answer should not necessarily stop unrelated preparation, and two completed inputs should not make the entire account appear ready. Owners work from the dependencies of their actual tasks; Priya reviews the broader case.

Record what the delivery specialist did in Completion Evidence, such as the internal reference to the demonstration workspace and the date it was checked. Do not collect passwords, access tokens, or production credentials in this intake. Any required account access should follow the organization’s approved authentication process.

Resolve a sales promise that does not match the checklist

Suppose Jo writes that Northline expects a custom historical-data migration. The sales scope describes only standard reporting setup. Priya records the mismatch in Handoff Questions and marks the affected task Blocked. Alex checks the agreed documents and discusses the discrepancy through the team’s normal customer communication process.

Preserve both the customer’s wording and the reviewed scope. Do not quietly rewrite Agreed Scope to make the inconsistency disappear. Record the resolution, who confirmed it, and what changed in the plan. If additional work requires commercial approval, keep it pending until that separate decision is made.

A customer response cannot by itself authorize an expanded service commitment. Likewise, an internal Ready status does not schedule a migration or promise a launch date. If the mismatch remains unresolved, Priya keeps Handoff State out of Handoff Complete and identifies the next owner.

Make completion a human acceptance step

Once Jo supplies the operational contact, Priya checks all required inputs, reviews required setup tasks, confirms Scope Checked and Ownership Accepted, then records Handoff Complete with reviewer and date. She also verifies that every remaining delivery task has an owner and a next step. The handoff can finish while clearly assigned implementation work remains open.

Case creation, checklist creation, dependency review, and the completion decision are manual here. Deal stage changes do not automatically create tasks. If you later add an automation for won deals, test duplicate prevention, re-opened deals, and the case where the success owner is missing. Notifications and scheduling require their own configured steps.

Before rollout, use two fictional customer contacts and cases. Confirm that neither can see the other’s inputs or reach internal sales notes. Save an incomplete response, return one item for clarification, and leave a required prerequisite unresolved. Verify that the case remains visibly incomplete in each situation. Test the shared published portal, not just the builder.

The broader customer portal guide covers other account-facing records. Start with this narrower onboarding handoff when the immediate problem is information getting lost between sales and delivery. A useful checklist makes the missing fact and its next owner obvious, then leaves the final readiness decision with the person taking responsibility.