Client requests and messages

Understand The Queue

Open Requests from the firm navigation. The web workspace has two views:

• Open groups active statement, bank-connect, and bank-reconnect obligations by company. Each company starts as one collapsed row.
• History keeps the corresponding closed obligations grouped by company.

Expand a company to see each requested item, the first ask date, and how many asks were delivered. A company can show separate statement and bank-feed counts so the firm can see the work without opening every request thread.

The grouped page is a working summary. Open an item when you need the full thread, files, delivery history, assignments, or internal workflow status. Resolved and dismissed threads preserve that 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.

Reply From A Request

Open the request thread, enter the message, and send it to follow up with the owner. Staff replies use the request's outbound delivery path, including email and a text notification to eligible recipients. The thread records the reply and returns to waiting for the customer.

The text includes a secure request link. Owners reply through that link or email; SMS itself remains outbound-only. See Messaging and channels.

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.