Request-to-Delivery and project updates

Two related ways to keep work moving and keep the client in the loop: a Request-to-Delivery board for tracking individual work requests from intake to delivery, and Project updates for posting progress notes the client can reply to. Both live in the client portal and mirror to an admin view.

What the Request-to-Delivery board is

The board is a kanban-style view of work requests. Each request is one piece of work (a feature, a change, a deliverable) that moves left to right through delivery. Clients see it at /dashboard/requests; admins see every client's requests at /admin/requests. Each request is stored as a DeliveryRequest, with its thread of messages stored as DeliveryRequestComment rows.

Columns and statuses

The board has seven columns, in this exact order:

• Requested: the default for a new request. This is where client-submitted requests land.
• Planned: accepted and scheduled, not started yet.
• In Progress: actively being worked.
• Client Review: delivered for the client to check before sign-off.
• Delivered: done. When a request first moves to Delivered, the portal stamps a deliveredAt date on it; moving it back out of Delivered clears that date.
• Blocked: stalled on something (waiting on the client, a dependency, etc.).
• Cancelled: dropped, no longer being worked.

A request also carries a priority: Low, Normal, High, or Urgent (Normal is the default). Priority shows as a pill on the card and doesn't affect which column the request is in.

How clients submit and track requests

From /dashboard/requests, a client uses the New Request form:

• Title (required): what they need delivered.
• Project (optional): tie the request to one of their active projects, or leave it as a general request.
• Priority: Low / Normal / High / Urgent.
• Details (required): goals, acceptance criteria, constraints. Links and references go here as text.

Client-submitted requests always start in Requested. The client can't set the status or a due date themselves. After submitting, the request appears on their board grouped under its column, and they can follow it as the admin moves it across.

On each card the client sees the status pill, the linked project (if any), when it was last updated, the due date (if the admin set one), and the delivered date (once it's delivered). They can post a reply on any request to ask a question or add context. Replies show in the thread labeled "You" (or the business name for the admin's messages).

The Details field and reply box support voice dictation (the mic button on the text area). See Tracking time and managing projects for how dictation works elsewhere in the portal.

How admins respond

From /admin/requests, the admin sees the same board across all clients, plus a Create Request form. Admins can do more than clients:

• Create a request on a client's behalf: pick the client, set a title and details, optionally link a project, and set the starting status, priority, and a due date. If a project is selected, the request is owned by that project's client.
• Edit any request inline: each card has a form to change the title, details, linked project, status, priority, and due date. Changing the status is how the admin moves a request between columns.
• Post an update to the request thread.

When an admin changes a request's status, the client gets a portal notification about the change. When an admin posts a thread update, the client gets an update notification. When a client submits a request or replies, the admins get a notification on their side. Every create, status change, and comment is also written to the activity log.

Threads and attachments on requests

Each request has one comment thread shared between client and admin. On the admin board, each message is tagged Admin or Client with the author shown, and each card lists the three most recent comments. On the client board, your messages appear under your business name and the client's under their own, and the full thread is shown.

Attachments and links on a request live as text inside the Details field or a thread message. The request comment form is a message box, so to share a file, paste a link to it. To attach an actual uploaded file, use Project updates below, which has file upload built in.

Due dates

Only admins set due dates, either when creating a request or by editing it. When a request has a due date, it shows as a "Due …" line on the card for both the admin and the client. The due date is informational. It doesn't move the request between columns or block anything on its own.

Project updates

Project updates are progress notes an admin posts on a specific project. The client reads them and can reply in a thread under each note. Clients see these at /dashboard/notes (titled "Client Notes"). Each note is a ProjectUpdate; each reply is a ProjectUpdateReply.

This is different from the delivery board: updates are tied to a project, not an individual request, and updates are posted by the admin (clients can only reply), whereas on the delivery board the client can open the request.

How admins post updates

From a client's workspace at /admin/clients, open the Notes view for that client. For any project, type the update body and post it. When an admin posts a project update:

• The client gets an email letting them know a new note was posted.
• The client gets a portal notification ("New note on …") linking to /dashboard/notes.
• The action is recorded in the activity log.

Admins can also attach a file to a posted update with the Attach File button on the update. Uploaded files show under the note for both sides.

How clients reply

On /dashboard/notes, projects are listed in an accordion with the most recently active one open. Under each project, every update shows with its replies in a thread. The client replies with the Send Client Note box and can Attach File to add an upload to the thread. When a client replies, the admins get a notification ("… replied to a note on …").

Replies are labeled by author: the client's own replies read "Your Note" and the admin's read with the business name. The reply box supports voice dictation.

Admin preview is read-only

When an admin previews a client's portal (the "Admin Preview" badge), both the request board and the project-notes view become read-only: the admin can see everything the client sees but can't submit requests, post replies, or attach files as the client. Only the real client can do that.