How the screen is organised
Deliverables are not presented as one long queue. They are grouped under the project they belong to, and that structural choice matters more than it sounds.
A flat queue invites a client to review items in the order they arrived, which is exactly the wrong order. Grouping by project means a client reviews three logo variants together, sees them as a set, and gives one coherent answer instead of three inconsistent ones. It also makes it obvious when a project has five things waiting and another has none.
Each card carries the deliverable’s name, a status badge, a file-type icon, the file itself for viewing or download, and — once there has been a round of feedback — the client’s own previous comments. Updates arrive live, so a deliverable submitted while a client has the tab open appears without a refresh.
Five statuses, and which two need you
The status badge is the whole navigation system for this screen. Two of the five statuses mean a client can act; three mean they cannot, and should not try.
| Status | Colour | What it means | Can you act? |
|---|---|---|---|
| Pending | Grey | Logged as expected but nothing has been handed over yet. | Yes |
| In Progress | Purple | The agency has started it. This is a courtesy signal, not a request for anything. | No |
| Submitted | Blue | Handed to you and waiting. This is the only status that means the ball is genuinely in your court. | Yes |
| Revision Requested | Amber | You have sent feedback and the agency is working through it. The buttons are replaced with a note that the agency is revising. | No |
| Approved | Emerald | Signed off by you. The action buttons are gone for good on this item. | No |
The one to train yourself on is blue. Submitted is the status that means work is waiting on a human decision, and it is the only badge worth reacting to immediately. Purple and amber are both “the agency has it”, and the useful response to both is patience.
Arpixa is also forgiving about how the agency side words things. A status stored as pending_review is shown to the client as Submitted, and revisions_requested and revision_requested both display as Revision Requested. The client never sees the underlying vocabulary, only the five labels above.
The decision: approve, or send it back
When a deliverable is actionable, two buttons appear side by side. Here is how to choose between them without either rubber-stamping or nitpicking.
| Approve when… | Request revisions when… |
|---|---|
| It does the job it was scoped to do, even if you would have made different choices. | It does not do the job it was scoped to do, and you can say which part. |
| Your remaining notes are preferences, and you are willing to live with them. | Your remaining notes are requirements, and shipping without them would be wrong. |
| Anything downstream is blocked and the item is good enough to unblock it. | There is a factual error: a wrong price, a misspelt name, an outdated logo. |
| You have already been round twice and the remaining gap is taste, not correctness. | You cannot judge it yet because something is missing, in which case say what is missing. |
The failure mode worth naming: approving with a caveat in a separate message. “Approved, but can we tweak the header” produces a deliverable marked final and a change request with nowhere to live. If there is a change, request revisions. If there is not, approve cleanly. The module deliberately gives you no third option.
Writing revision feedback that works
Choosing Request Revisions opens a form with a heading naming the deliverable, a required feedback box labelled Feedback & Required Changes, and a priority selector. The box is prompted with “describe what needs to be changed”, and the form will not submit while it is empty.
That single constraint eliminates the worst thing a client can do in a review loop, which is reject work without explaining why. But required is not the same as useful, and the difference between a one-round revision and a three-round one is almost entirely in this box.
Three habits do most of the work:
- Point at the thing. “The pricing table on page 3” is actionable. “The pricing section” is a search task.
- Say what is wrong, not what to do. “The middle tier reads as the cheap option and it should be the recommended one” gives an agency room to solve it well. “Make it blue” does not.
- Separate must-fix from nice-to-have. Two labelled lists in one box costs you thirty seconds and saves a round trip, because the agency knows what it can defer.
Whatever gets written here is shown back on the card afterwards under a Your Feedback heading, so vague feedback is vague for you too when the next version arrives. There is a broader version of this argument in how to share deliverables with clients.
Choosing a priority honestly
The priority selector offers four levels and starts on Medium. It does not change what the rework is; it tells the agency where to put it in the queue.
| Priority | What it should mean |
|---|---|
| Low | Fix it whenever you next touch the file. Nothing downstream is waiting on this. |
| Medium | The default, and the right answer most of the time. Normal turnaround, normal queue position. |
| High | Something else is waiting on this. Say what in the feedback, because High without a reason gets discounted. |
| Urgent | A dated commitment is at risk. Spend this one carefully; an agency that sees four Urgents in a row stops reading the field. |
Priority fields fail in one predictable way: everything becomes urgent, and the field stops carrying information. Medium being the default is a nudge in the right direction. Using it as the default in practice too is what keeps High and Urgent meaningful for the one week a year you genuinely need them.
Why approval is one-way
Once a deliverable is Approved, the approve and revise buttons are gone from that card. There is no client-side undo. This surprises people, and it is the right design.
An approval that can be withdrawn is not an approval, it is an opinion. Agencies scope, schedule, invoice, and move on from sign-off points, and all of that depends on sign-off meaning something. Making the button final is what turns a click into a record.
It also cuts the other way, which is worth saying to agencies: because approval is irreversible from the client side, it has to be obvious what is being approved. A deliverable submitted with a vague name and no context invites either a stalled review or a regretted click. Name the thing precisely, and submit it when it is genuinely ready.
The corresponding state on the other side, Revision Requested, is also a lock. While the agency is revising, the client cannot pile on more feedback; the buttons are replaced with a note saying the agency is working on it. That prevents the pattern where one deliverable accumulates four rounds of contradictory notes before anyone has acted on the first.
Get sign-off without a chase-up email
Start free in minutes, or log in to your Arpixa workspace. See pricing for plan details.
Review and approval are not gated behind a tier. What an Arpixa plan changes is how many clients a workspace can run: one free, twelve for $12 a month, and no cap at $29 or $89 a month. See pricing.
What the version number does and does not tell you
When a deliverable has been superseded, the card shows a version number. Be precise about what that is: it is a count of how many times the item has been replaced, not a browsable archive.
What it gives you is context, and that is genuinely useful. Version 2 means one round has happened. Version 4 means three have, and if you are about to write more feedback on a version 4 deliverable, the number is telling you something about whether written feedback is still the right instrument. At that point a fifteen-minute call — which you can request from the Calendar — is usually cheaper than a fifth round.
What it does not give you is a side-by-side comparison or a way to open version 2 from the client view. If you need an earlier file back, ask the agency; on their side the project workspace retains the history. The agency-side view of the same loop is described in Projects.
How to review a deliverable
- Open Deliverables and find the project the item belongs to.
- Look for blue Submitted badges. Those are the only ones asking anything of you.
- Open or download the file and actually look at it against what was agreed.
- Decide: does this need another pass, or is it good enough to sign off?
- If it needs work, choose Request Revisions, write the specific changes, and set a priority.
- If it is right, approve it, and accept that approval on this item is final.
One habit is worth adopting deliberately: review in project batches rather than one item at a time as notifications arrive. The screen is grouped that way for a reason, and a set of related deliverables reviewed together produces more consistent feedback than the same items reviewed across three days.
Frequently asked questions
What is the Deliverables screen in the Arpixa client portal?
It is where a client reviews the work an agency hands over. Deliverables are grouped under the project they belong to, each with a status badge, the file, and the two actions that matter: approve, or request revisions with written feedback. It is the client half of the review loop the agency runs from their project workspace.
How does a client approve a deliverable?
By opening Deliverables, finding an item marked Submitted or Pending, and choosing the approve action on that card. Approval takes effect immediately and, once given, the approve and revise buttons no longer appear on that deliverable. It is treated as a decision rather than a toggle.
Can a client undo an approval?
Not from the portal. Once a deliverable is Approved, the action buttons are removed from that card, so there is no self-service way back. If something was approved by mistake, the fix is a conversation with the agency, who can submit a new version for review. The deliberate one-way design is what makes an approval worth having as a record.
Is feedback required when requesting revisions?
Yes. The revision form will not submit with an empty feedback box, and the field is marked required. This is the single most useful constraint in the whole module, because it makes it impossible to reject work without saying why.
What do the four revision priorities mean?
Low, Medium, High, and Urgent, defaulting to Medium. They tell the agency how to queue the rework rather than changing what the rework is. Medium is the honest answer most of the time; High and Urgent are worth reserving for cases where something downstream is genuinely blocked.
What does the version number on a deliverable mean?
It is a count of how many times that deliverable has been superseded, shown as the current version number. It tells you whether an item has been through the loop once or four times, which is useful context before you write more feedback. It is a counter rather than a browsable history, so there is no side-by-side comparison of earlier versions in the client view.
Can a client see their own past feedback?
Yes. Once a deliverable is in Revision Requested or Approved, the feedback the client wrote is shown back to them on the card under a Your Feedback heading. That closes a gap most review tools leave open, where you send comments and then cannot remember exactly what you asked for.
What happens after a client requests revisions?
The card switches to amber, the approve and revise buttons are replaced with a note that the agency is revising, and the request goes to the agency with the feedback and priority attached. The client cannot send more feedback on that item until the agency submits again, which stops a single deliverable from collecting six rounds of contradictory notes.