“We’re waiting on the client.”
The client answered Tuesday.
The answer is in an email. The document is attached to a message. The task still says waiting.
Friday’s reminder just asked for it again.
Before measuring client delays, we might need to check our own inbox.
The answer arrived. What happened next?
A reviewer asks for a loan statement. The client sends it in a message instead of using the original request.
Someone reads the message. Perhaps they reply, “Thanks!”
The request remains open.
From the client’s side, the document was delivered and acknowledged. From the reviewer’s task list, it’s still missing.
Now somebody is following up on work the client believes they already finished.
That is a frustrating conversation to have twice.
Read, received, reviewed, resolved
Those words describe different things.
A message can be read while its attachment still needs review. A statement can be received for the wrong month. A document can answer one part of a question while another part remains open.
Changing every request to complete as soon as a file arrives would leave another set of problems.
The reviewer needs to identify which request the response addresses, inspect what arrived, and record what remains outstanding.
“The statement covers August. September is still needed” gives the client a specific next action.
“Still waiting on documents” asks them to reconstruct our request and guess what was wrong with their response.
This is a BrokenBooks requirement
In BrokenBooks’ client portal and request workflows, I’m working on keeping client communication connected to the accounting issue behind it.
A response and its attachments need a path back to the request they support. The reviewer’s conclusion needs to remain available too.
That includes documents sent through a conversation. A client shouldn’t have to understand our internal organization before their answer can be useful.
Attachment routing and the transitions between receiving, reviewing, and resolving information are part of the work being developed and validated. The requirement is clear: the next person needs to know whether the answer was sufficient.
A message marked read won’t tell them.
Give waiting a reason
There are legitimate reasons for work to remain open after a reply.
The supporting period is incomplete. The answer introduces another question. A statement confirms the payment but doesn’t explain the original loan balance.
Record that reason.
The firm can then see what needs review, what needs another request, and what is actually waiting on the client. The client can understand what to send next.
That continuity belongs throughout the BrokenBooks engagement workflow, from the first review through corrective work and handoff.
BrokenBooks is currently in private-beta testing. You can get development updates here.
Sometimes the client is holding up the work.
Sometimes we’ve lost track of what they already sent.
