Decide whether a custom portal is justified
Begin with one client’s current intake and delivery process. If your existing project-management tool already supports its queue, permissions and client view, configuring that tool may be enough. Custom development becomes useful when requests need a distinct account experience, agreement context or a supported integration across systems. Identify the authoritative task system before estimating a portal. Keep the first release focused on intake, a named scope decision and an understandable queue rather than rebuilding time tracking, invoicing and project management together.
Use delivered application work as the engineering reference
Reveal Software’s published delivery comprises a Next.js web application, a browser extension for personal video walkthroughs and an admin dashboard for users, roles and activity. React, TypeScript, Hono, Drizzle ORM and PostgreSQL connect those surfaces. The project is recorded in Romania. Lizzt, recorded in the Netherlands, covers a responsive Next.js frontend with shared tasks, costs, chat and participants on an existing Supabase backend. Its scope was a frontend rebuild, not a new retainer backend. Neither case is presented as delivery of this agency workflow.
Give each request a brief and an agreement context
Agree the minimum information needed to review a request: client account, intended outcome, target page or product, supporting material and a requested date. A requested date is an input, not an accepted deadline. Reference the relevant agreement or service period so staff can assess scope against the approved terms. Explain missing information and allow an explicit clarification step. Avoid collecting production passwords in a brief; decide separately how approved access is provided to the delivery team. Start with representative requests rather than a generic form with every possible field.
Separate submission from scope acceptance
A client submitting a request should receive confirmation of receipt and its current review state. Define who can accept the work, ask for information, decline it or propose a separate engagement. The portal records those decisions; it does not interpret a contract automatically. An out-of-scope item can remain visible without entering the committed delivery queue. Record the decision maker and the agreed next step. If AI helps summarize the brief, keep the original available and require the responsible agency person to make the scope decision.
Choose how capacity and priority are represented
Decide whether the agreement promises one active request, a bounded queue, a time allowance or another arrangement. Model the approved rule instead of suggesting unlimited capacity. Agree who can reorder requests and what happens to work already in progress. Queue position alone does not establish a delivery date. Show a scheduled date only when the agency has confirmed one. If time tracking or remaining allowances are included, identify the record that owns those values and how corrections are handled; do not calculate billable totals from a task status.
Use four requests to test the triage rules before building
Use fictional client accounts and approved sample agreement references to walk through these four proposed cases. For each, record the authoritative request ID, decision owner, client-visible state and next action. Compare the same cases in your existing tools before commissioning a portal. Reveal demonstrates connected application and administration surfaces; these agency rules are new requirements. This worksheet does not decide contract scope or billing, and it has no answer fields or storage.
Agency request triage worksheet: four proposed review cases
1. The brief is incomplete
- Ask
- Does the request stay awaiting clarification, and who asks the client for the missing outcome or target?
- Evidence to request
- One request ID, a clear missing-information message, a clarification owner and the state shown to that client.
- Tradeoff to record
- Receipt can be confirmed without accepting the work. A requested date stays an input while the brief is unresolved.
2. The request needs a separate scope decision
- Ask
- Who compares the request with the approved agreement, and how does the client see a proposed next step?
- Evidence to request
- The agreement reference, named reviewer, recorded scope decision and client response before work enters the accepted queue.
- Tradeoff to record
- Keep the request visible without treating it as accepted work. Neither a submitted brief nor an AI summary establishes billable time.
3. Priority changes while another request is active
- Ask
- Can the client reorder waiting requests, and who decides whether active work pauses?
- Evidence to request
- Two waiting request IDs, one active item, the permitted priority change and the updated client view after agency review.
- Tradeoff to record
- Changing queue position is different from interrupting active work or confirming a delivery date. Record those decisions separately.
4. The delivery-system handoff is uncertain
- Ask
- What does the client see when receipt is recorded but creation of the delivery task cannot yet be confirmed?
- Evidence to request
- The original request ID, any known task reference, an explicit unresolved handoff state and the staff member who reconciles it.
- Tradeoff to record
- Check the authoritative task record before repeating creation. A silent duplicate can split priority and ownership across two tasks.
Keep the client view and internal delivery state aligned
Define which statuses a client sees and which notes remain internal. Agree whether an assigned task is authoritative in the portal or in an existing delivery system. A failed synchronization needs an explicit state and a recovery owner rather than a second silent task. Review a request reassigned between staff and a priority change made from another screen. Client access must follow the agreed account boundary in server-side checks, not merely a filtered interface. Withdrawn access and a former client contact belong in the acceptance examples.
Close the request with a deliberate delivery handoff
Name the result a client should receive: a published page, a preview, a file or an explanation of the completed change. Decide who reviews it and what constitutes completion. Additional revision requests may reopen the same item or create another request under the agreement; choose that rule before implementation. This page addresses acceptance and prioritization of retainer work. Creative file-version approval is a separate buyer task already covered in our asset-approval guidance.
Follow one request from submission to an agreed queue position
For a new engagement, bring two client accounts, their approved agreements and representative requests. Proposed acceptance examples: a submission remains awaiting triage until an authorized person accepts it; an out-of-scope request needs a separate decision; reordering displays the agreed current priority; and a client cannot read another account. Include a missing brief and an interrupted update. These are proposed agency requirements, not claims about historical Reveal or Lizzt retainer capabilities.
Work with a US company and an Ankara-led engineering team
Curiosive LLC is a US company, with engineering led from Ankara, Türkiye. Monthly AI-accelerated development starts from $2,000, with scope, capacity and operating responsibilities confirmed in writing. Bring an approved agreement, two client-account examples, several real request patterns and the tools your team currently uses. Agree US review windows and a bounded first release. Your agency owns its client agreements and capacity commitments; engineers implement the approved records, permissions and integrations.
