Client requests and messages

Client Requests is the firm-wide communication queue for every managed company. Use it to ask for an answer or document, assign work, send a message, follow a thread, or supervise a reply Tally is handling. The same queue is available in accountant mobile.

Open Requests from the firm navigation. Filter by company or workflow state, or search for a subject, owner, company, or message.

Understand The Queue

The main states explain who needs to move next:

• Waiting on client — the request or message has been delivered and the company owner needs to answer;
• Tally working — a reply has arrived and Tally is taking the first pass;
• Needs firm — Tally or the communication system needs a person at the firm;
• Follow-up due — an open thread reached its reminder or follow-up time;
• Resolved — the request reached a recorded completion;
• Dismissed — the firm intentionally closed it without completion;
• Held inbound — an inbound message could not be attached safely and needs firm review.

Resolved and dismissed threads preserve their history and can be reopened when new follow-up is required.

Ask For An Answer Or File

A request can ask for a statement, receipt, document, answer, or task. Include a clear subject, a short plain-language question, a due date when useful, and the related account, period, or transaction.

Company owners receive the request through the configured delivery channel and can use a secure no-login link when the workflow provides one. The link is scoped to that request; it does not grant broad access to the company books.

Statement replies go through the shared statement store and OCR verification. The request should resolve only after the file matches the expected account and period or a firm user handles the exception.

Send A Message

Choose the message type when the firm needs to tell an owner something rather than request work—for example, that June reports are ready. A one-way message can resolve on delivery so an informational note does not remain as artificial work in the queue.

If the owner replies, the same thread reopens and preserves the full exchange. Replies, uploaded evidence, assignments, closure reason, and delivery history remain together.

How Tally Handles Replies

When authorized client-request automation is active, Tally takes the first pass on an owner reply. Tally reads the conversation, the accountant-only company brief, and the firm's standing instructions before deciding what to do.

Tally may answer a routine question, acknowledge and resolve a simple message, request more information, or route the decision to the firm. Pricing, complaints, sensitive topics, and other judgment-heavy messages should be routed rather than improvised.

If Tally does not finish within the supervision window, the request moves to Needs firm instead of waiting indefinitely.

Work A Decision Packet From Email

When Tally routes a message, the designated firm handler can receive a decision packet containing the owner's message, Tally's routing reason, and a draft reply. Reply normally to send the edited response through LedgerHQ and record it on the request thread.

Start the first line with @tally when the email is an instruction for Tally instead of the answer to the owner. For example:

@tally Send the June P&L and tell them we expect to close Friday.

Only validated firm-member replies are accepted by this bridge. Quoted email history is removed before the reply is stored or relayed.

Review What Tally Learns

Edits to Tally's drafts and explicit @tally instructions can produce a staged learning proposal. The proposal may become a firm standing instruction, a small Tally memory, or an addition to the company brief's communications section.

Nothing is learned automatically. Approve a proposal when it should guide future work, or dismiss it when it was specific to one conversation. The Client Messages scoreboard summarizes handling and draft-acceptance outcomes so the firm can expand autonomy from evidence.

Resolve, Dismiss, Or Reopen

Resolve when the firm received what it needed or the message reached its goal. Record a useful closure reason and summary. Dismiss when the request was no longer needed or was created by mistake. Reopen when a resolved thread still needs follow-up.

Use bulk resolution only when the selected requests truly share the same outcome. An empty queue is useful only when the closure history remains honest.