An Airtable retainer portal can give clients one place to submit monthly requests and see the work your team has actually accepted. Link each request to a service period, keep client priorities separate from the delivery queue, and record deferrals explicitly. miniExtensions supplies the portal experience; your account manager still decides scope, sequencing and commercial questions.

Imagine fictional Cedar Studio maintaining a website for Harbor Workshops. During November, Harbor asks for a landing-page update, two article layouts and a new booking integration. The first three may fit the team’s current plan, while the integration needs a separate discussion. A portal should make that distinction visible rather than treating every submitted request as included work.

Give each service period its own record

Create these proposed tables in a connected Airtable base. Start with fictional contacts and requests, and agree who maintains each staff-owned field.

  • Contacts: Name as primary single-line text, Email as an email field and Client name as text. Use one record per portal user.
  • Service periods: Period label as text, Contact as a linked record to Contacts, Start date and End date as dates, Agreed scope summary as long text, Agreement reference as text and Period state as a single select.
  • Requests: Request title as text; Contact and Service period as linked records; Requested outcome and Client notes as long text; Requested priority as a single select; Desired date as a date; Files as an attachment; Delivery state as a single select; and Staff summary as long text.
  • Requests, staff planning fields: Scope decision as a single select, Owner as text, Queue position as a number, Confirmed target as a date, Delivered link as a URL, and Related request as a linked record to Requests.

For November, create period “Harbor / November” and three ordinary content requests. Record the booking integration separately with Scope decision set to Needs discussion. The summary should say what is being assessed, not merely display a red status. The client can see that the request was received without concluding that delivery is promised.

The period record holds the context used for that month. When the agreement changes, staff creates or updates the appropriate future period deliberately. Do not silently revise earlier scope summaries to make past decisions appear to have been based on terms that were agreed later.

Build a client queue without exposing planning controls

Create a miniExtensions Portal using Requests as its Data Table and Contact as its User Field. If you also display Service periods, its own Contact link supplies the direct user relationship. The Users table guide explains why an indirect relationship through another table is insufficient for a portal data table.

Configure verified login through Users & Login. The email verification guide describes the verification option on the email login field. Then open Portal Tables, select Requests, go to Views and select each private view. Under Filter and Sort, set Choose Records to Display to Personal records only (linked to the logged in user), following the personal-record guide.

Let clients enter Requested outcome, Client notes, Requested priority, Desired date and Files. Keep Scope decision, Owner, Queue position, Confirmed target and Delivery state outside their editable inputs. A client marking something Important is a request for prioritization, not an instruction that automatically displaces already accepted work.

For the first version, staff creates the period-linked request records after collecting the client’s initial list, then clients supply details through the portal. This avoids relying on an untested period selector or automatic relationship assignment. If you later allow new request creation, verify the user and period links and the selector’s actual scope before launch.

Turn intake into an agreed working sequence

Use your own Delivery state choices, such as New, Clarification needed, Queued, In progress, Delivered and Deferred. The account manager reviews new requests, decides whether enough information is available and maintains the queue. Nothing in this schema automatically calculates entitlement, billable time or remaining retainer value.

For the landing-page update, the client supplies the desired outcome and draft copy. The manager confirms the agreed work and records a target date. For the booking integration, the manager explains the missing decision in Staff summary and leaves it outside the accepted queue. Keep any quotation or contract amendment in the business’s normal approval process.

When two requests compete for the same delivery window, discuss the tradeoff and update Queue position and Confirmed target after an actual decision. Preserve the distinction between the client’s Desired date and the team’s confirmed date. That makes the queue useful for planning without turning a preference into a commitment.

Close a month without losing deferred work

Suppose one article layout remains unfinished at month-end. Leave its original Service period link intact and record why it is Deferred. If the work is agreed for December, create a December request linked through Related request and explain the continuation in Staff summary. Check for an existing continuation first so one deferred item does not become two active tasks.

Decide which completed records clients may still edit. Put Delivered and Deferred records in a separate history view and follow the record-editing restriction guide. Disable expansion and editing in that view, then inspect alternate views, creation and unlinking controls as well. A history view does not make the same record read-only if another accessible route still permits changes.

Use a new follow-up request when a delivered item needs additional work. That preserves what the earlier delivery contained and lets the manager decide whether the follow-up is a correction, a new request or a scope change. The project change request guide covers a more formal baseline-and-assessment process.

Check a complete monthly cycle

Test two fictional clients and two service periods. Confirm that each client sees only the intended records and cannot edit staff planning fields. Submit a missing brief, defer one item and carry it forward once. Then inspect the old period to confirm it still explains what was received, accepted and delivered.

These are recommended checks, not observed runtime results. Notifications, time tracking and billing remain separate work. A useful first version gives the client a clear next step and the account manager a queue they can explain, while keeping monthly decisions grounded in the actual agreement.