A document request can have the right checklist and still go to the wrong people, so I stopped treating recipients as background client metadata.
The request was ready.
It had a client, a period, a due date, and four specific document items:
Bank statement
Payroll report
Sales export
Receipt batch
Then I got to the Send action and realized there was still one piece of information I didn't want hidden somewhere else:
Who is this actually going to?
For a small bookkeeping request tool, that became a UI priority question rather than just a contact-management question.
A perfectly structured request is not very useful if the people receiving it are wrong.
A client isn't always one inbox
It is easy to model a request as:
Client
→ Request
→ Email
That works until the client's documents are controlled by different people.
The owner may have the bank statements.
A payroll contact may handle payroll reports.
Someone else may export sales data.
The person who sent last month's receipts may not be the person who should receive every future request.
I didn't want the request screen to make the team remember all of that after they had already decided what to ask for.
So the contact list became part of the request context itself.
For the current client document request workflow, the useful setup information sits together conceptually:
Client
Period
Due date
Request items
Contact list
That last line matters before anything is sent.
I wanted the answer visible before Send
One of the small details I kept in the request setup example is a recipient summary:
Contacts
2 send-to
Send to Morgan + Jamie
It is not a complicated feature.
But it answers the right question at the right moment.
If the user is about to send a monthly-close request, this is when they should be able to notice:
Wait, Jamie shouldn't receive this one.
or:
Morgan isn't enough. Payroll needs to go to the other contact too.
If the recipient information only lives on a separate client profile page, the team has to remember to check it.
If it only becomes visible after the email is sent, it is too late.
That is why I think of recipient visibility as part of the send decision rather than as background account data.
The important interface question isn't just:
Is this a valid contact?
It is:
Are these the right contacts for this request?
The checklist and recipients solve different problems
I also didn't want to merge recipients too tightly with individual requested documents in the first version.
It would be possible to build something much more elaborate:
Bank statement → Morgan
Payroll report → Jamie
Sales export → Taylor
Receipt batch → Morgan + Jamie
Then each item could have routing rules, defaults, exceptions, and its own notification history.
That may be useful for some systems.
It is more machinery than I need for the current scope.
The simpler request-level model still solves the immediate problem: choose the contacts who should receive this request, then send one client-facing upload path around that client and period.
The checklist answers:
What do we need?
The contact list answers:
Who should receive the ask?
Keeping both visible before Send gives the team enough context without turning the request builder into a routing engine.
The period belongs in the same decision
Recipients alone are not enough either.
A contact who should receive a May monthly-close request may not belong on a year-end cleanup request.
That is another reason I like keeping the send decision close to the request context instead of treating it as a generic email action.
The page is already organized around:
Bright Leaf Coffee
Current month
Due date
4 items
2 send-to
Those details describe one specific ask.
The request is not just an email to Morgan and Jamie. It is an ask to Morgan and Jamie for a particular client period and a particular list of documents.
When the same client has several periods open, that context becomes even more important. A Q2 cleanup request and a current-month request should not turn into one ambiguous thread.
So I want the send surface to preserve the combination, not just expose a recipient field.
I would rather catch this mistake before the message exists
There are plenty of mistakes software can recover from later.
Sending a request to the wrong contact is one I would rather make harder to create in the first place.
Once an email exists, the team may need to explain why someone received it, forward the request to somebody else, or reconstruct which person actually owns the missing documents.
Nothing technically catastrophic happened.
The request sent successfully.
The link worked.
The checklist was correct.
The failure was simply that the interface let the user act without enough visible context.
That is the kind of UI problem I find easy to underestimate.
A Send button looks like the important part because it performs the action.
But sometimes the more important part is the small line immediately above it telling you who the action will affect.
For this request flow, I don't need a sophisticated delivery-routing system yet.
I do want the team to see the recipients while the decision is still reversible.
Send to Morgan + Jamie is a small piece of UI.
It carries a lot more responsibility than it looks like.
Top comments (0)