Build an Airtable enquiry tracker: intake, owners and follow-up states

Use one record per enquiry

Decide whether a row represents a person or an individual enquiry. This tracker uses the latter so two requests from the same customer remain distinguishable. Define success as finding brochure requests that still need a reply, rather than building billing and sales management at once. Prepare three fictional records for the first review and keep production contact details out of the exercise.

Create fields with deliberate types

Add Request ID, Received at, Subject, Category, Reply address, Owner, State and Next action date. The identifier must survive sorting and reassignment. Use an email field for the reply address, dates for deadlines and controlled choices for category and state. Keep free-text descriptions separate from values used for filtering. Avoid making a person's name the primary key for an enquiry.

Agree what each state means

Choose states such as New, In progress, Awaiting reply and Complete. Each should explain who acts next. A vague On hold state needs a reason and a review date. Decide which information must be present before closing a request, and how unassigned work is checked. Color can reinforce those states, but the labels should remain understandable without it.

Collect public fields through a form

Build an Airtable form exposing only the subject, category, reply address and message needed from the submitter. Internal ownership and notes do not belong in that public questionnaire. Treat ordinary form submission as creating a new record, not as a secure way to update any existing request. Compare the preview with the published form URL and check the record actually stored after submission.

Create open-work and overdue views

Filter one view to unfinished states and another to unfinished items whose next action is overdue. Group by owner while keeping unassigned work visible. A record disappearing from a filtered view has not necessarily been deleted. Compare every practice record against the underlying table and both views, confirming the filter means what the team expects before using it as a daily queue.

Preserve useful follow-up history

For a small workload, dated notes may be sufficient. As work grows, add a linked follow-up table instead of repeatedly overwriting the previous action. Preserve enough history to understand an owner change or earlier reply. Review collaborator permissions and external sharing separately. A filtered view is a presentation of data and should not be assumed to provide strict row-level access control by itself.

Walk three records through the process

Use a new brochure request, an item awaiting a response and a completed request. Reconcile the open and overdue counts, then close an item and verify the resulting display. Try an unassigned record and an invalid reply address. Establish a workable manual process first. Consider Make when notifications or cross-service writes are useful; a separate automation subscription is not inherently necessary for an intake table.

• Assign Airtable form responses: category rules and an unassigned queue
• Find unfinished work in Airtable views: filters, sorting and sharing checks
• Connect Make and Airtable: search, create and update intake records