The client stopped emailing. Before you mark the account healthy, check the last promise.
Matías Bonvin· Updated

Open the last email in a quiet client account. Find the sentence that says someone will do something.
Who owes the next move?
Suppose a service firm has delivered a project report. The client has stopped sending questions, the invoice is paid and the account looks uneventful in the weekly review. In the final email, however, the project manager promised to send a corrected version before the client could approve the next phase.
No corrected version appears in the shared folder. The account manager is preparing a friendly “just checking in”.
The useful next step is to establish whether the promised correction was delivered.
Compare silence with the work underway
A quiet account can be entirely healthy. The work may be complete, the client may be on holiday, or the relationship may have moved to a scheduled monthly meeting.
It can also conceal a stalled decision. You cannot distinguish those situations by counting emails alone.
Start with the current phase of the engagement and the expected next event. A client who normally approves at the end of each month should not generate a warning every quiet Tuesday. A missed approval matters more when it holds up work that both sides expected to begin.
For each account under review, collect the last agreed commitment, its owner and its date. Compare that with what was delivered and what the client acknowledged. Leave missing evidence visible. An empty folder may mean the document was sent elsewhere; it does not prove nobody sent it.
Give the account manager a small evidence file
An AI assistant can assemble a draft from authorised project records, meeting notes and client correspondence. Keep its access limited to the accounts and records needed for this work.
The draft should let the account manager inspect the evidence without reopening the whole engagement. A useful record contains:
- The expected next event, with the message or meeting note that established it.
- The latest delivery or response, with a source and date.
- Any unresolved issue that could explain the pause.
- An alternative explanation and the fact still needed to distinguish it.
- A proposed internal check, with a named owner.
For the report example, the assistant could identify the promise and the missing acknowledgement. The project manager then checks whether the correction was sent from another location. That check comes before a message telling the client they have gone quiet.
Avoid asking the model to infer satisfaction from tone. A brief reply can come from a busy, satisfied client. A warm reply can accompany a project that has lost its sponsor. Preserve what the person said and separate it from the team's interpretation.
Use the account's own rhythm
Before setting an inactivity threshold, look at the account's normal working pattern and the commitments in its current phase. Where there is little history, say so. A default threshold should be a review rule, not a claim that a relationship is at risk.
A changed contact may matter more than reduced message volume. If the sponsor leaves, establish who now owns the decision. If an approval is overdue, check whether the client received a usable deliverable. If the account has no agreed next step, the team may need to define one rather than chase an absent response.
Review false alarms too. When a warning turns out to be a planned pause, record that explanation. Otherwise, the same account can return to the list each week until people stop reading it.
Contact the client with something specific
Once the internal facts are checked, the account manager decides whether to contact the client and what to say. The assistant can draft a message. An inactivity flag should not send it automatically.
In the hypothetical report case, if the correction was missed, the message needs to acknowledge that and give a credible delivery date. If the correction was sent but never reached the right person, resend it to the confirmed contact and restate the decision it supports.
Both messages give the client something to act on. A generic check-in would have left the underlying problem untouched.
Measure the usefulness of this process by the commitments clarified and the blocked work resumed. Keep unsupported warnings visible as a cost. A fuller dashboard does not establish that fewer clients will leave, and an alert followed by a renewal does not prove the alert caused it.
Solve IT can connect the project and account records your team needs for this review, with evidence attached and approval retained by the person managing the relationship. Start with one account where the next move is unclear.
Bring the last promise, including the message it was written in.