Hands-On: Log a Client Interaction

Not all client interactions are the same — and your log entry should reflect the nature of the interaction, not just the fact that it happened. A phone call requires different documentation than a signed agreement. Understanding the distinguishing elements of each interaction type makes your log entries more useful to everyone who reads them:

• Phone calls — shorter, often informal, and frequently produce verbal commitments that need to be confirmed in writing. The log must capture who called whom, what was discussed, and what follow-up was promised — because nothing was written down during the call itself.
• Email threads — the interaction is already written down, so the log summary should not simply duplicate the email. Instead, summarize the key outcome: what decision was reached, what was agreed, and what action follows. Note the thread subject line so it can be located if needed.
• In-person meetings — typically the richest in content and commitments. Meetings produce the most complex log entries: multiple participants, multiple agenda items, and multiple next steps with different owners and timelines. Notes taken during the meeting are the raw material; the log entry is the organized output.
• Signed documents and agreements — the key log field here is confirmation of receipt: who delivered the document, when it was received, where the signed copy was filed, and what action it triggers (e.g., 'Countersigned copy to be returned by [date]'). Document logs protect both parties in future disputes.
• Every log ends with a next action — regardless of the interaction type, the final element of every log entry is always the same: what happens next, who is responsible, and when. A log that ends without a next action is an interaction that may not produce a result.

Phone calls are the most easily lost type of client interaction because nothing is automatically recorded. The only record of what was said and agreed is the one you create immediately after hanging up. A call log written 20 minutes after the call is noticeably thinner than one written within five minutes — log immediately:

• Date, time, and duration — log the call date, approximate start time, and approximate call duration. This information establishes context when reviewing the log weeks later.
• Participants — your name, any other TOR Tech participants, and the client name and title. If a new person was on the call who is not yet in the CRM, create their contact record before closing the log.
• Reason for the call — a single sentence explaining why the call occurred: 'Prospect inquiry call regarding IT support services' or 'Client check-in call — quarterly relationship review.'
• Summary — 3–5 sentences covering the main topics discussed and the key points made by each side. Avoid editorializing. Record what was said, not your evaluation of it.
• Next steps — list every commitment made by either party: 'TOR Tech to send service proposal by [date].' 'Client to confirm budget approval with CFO and respond by [date].' One named owner, one clear due date per item.

Email threads have a built-in record — the emails themselves. The CRM log entry for an email thread is not a duplication of the email; it is a distillation of the thread's outcome and a pointer to the original source. This distinction matters because a useful log tells the reader what was decided, not just what was written:

• Reference the thread — log the subject line of the email thread and the approximate date range. This enables anyone reviewing the record to find the original thread quickly if they need the full context.
• Summarize the outcome, not the content — write what was decided or agreed as a result of the thread: 'Contract revision approved by client; updated version to be sent for signature by [date].' The log does not need to repeat what the emails say.
• Note who initiated the thread and who responded — whether the communication originated with the client or with TOR Tech is relevant context that helps understand the relationship dynamic.
• Flag any open items — if the thread produced a question or request that is still awaiting response, note it as an open item with a due date for follow-up.
• Attach or link the thread — in CRM platforms that support it, attach the relevant email or a link to the thread directly to the log entry so the full source document is one click away.

In-person meetings generate the most complex log entries because they typically involve multiple participants, multiple agenda items, and multiple commitments. The discipline of logging a meeting well separates assistants who treat meetings as events from those who treat them as decisions:

• Capture all participants — list every person present on both sides, with their name and title. A meeting attended by three TOR Tech staff and two client representatives has five participants who all need to be named.
• Log each agenda item and its outcome — even if the meeting covered three topics, the log entry should have a one-to-two sentence summary for each. Do not collapse a three-topic meeting into a single vague paragraph.
• Separate discussion from decisions — note what was discussed versus what was decided. 'The team discussed three pricing models (discussed). The client agreed to proceed with the mid-tier option (decided).'
• Capture all commitments with owners and dates — meetings typically produce multiple action items owned by different people. List every one: who is doing what and by when. A commitment made in a meeting that is not written down is a commitment that is likely to be forgotten.
• Send a meeting recap email within 24 hours — after logging the meeting, send a follow-up email to all participants summarizing the decisions and action items. The follow-up email and the CRM log should tell the same story.

A signed document is a milestone — it represents a formal commitment. The log entry for a signed agreement is less about what was discussed and more about what was delivered, where it is stored, and what actions it triggers:

• Document name and version — log the exact document name and version number: 'TOR Tech Services Agreement v2.1 — Signed.' Ambiguity about which version was signed is a compliance risk.
• Delivery method and date — note how the signed document was delivered: email, DocuSign, physical delivery. Include the exact date received.
• Storage location — note exactly where the signed document was filed: the folder path in Google Drive, the contract management system record, or the physical file location. Anyone who needs to retrieve the signed agreement should be able to find it in under 30 seconds.
• Actions triggered by the document — a signed contract typically triggers follow-on actions: sending a countersigned copy, onboarding the client, issuing an invoice. Log those next steps with owners and due dates just as you would for any other interaction type.