The History tab

Every other tab on a client record answers a question about now. History answers questions about the past: what did we do with this person over the last few months, and what happened to the message I sent them last Tuesday.

Open a client and pick History.

The timeline

The card on the left is the client’s history: everything Protocol recorded about this client, newest first, with the date and time running down the left edge so you can read the rhythm of a relationship before you read any of it.

Protocol writes a history line at the moment something changes, as part of the same save, so the timeline is a record of what actually happened rather than a reconstruction:

• Stages: the client moved from one lifecycle stage to another.
• Labels: a label was added or removed, including labels your automations set.
• Programs: a plan was assigned, activated, paused, ended or deleted.
• Check-ins and forms: the client submitted a check-in or filled in a form.
• Payments: a purchase was created, changed status, was renewed or deleted, or an installment was paid.
• Emails: an email to the client went out, or failed to.
• Who processes the client’s check-ins changed.

    </div>
  </div>
  <div style="display:flex; gap:10px; align-items:flex-start; margin-bottom:8px">
    <div style="width:52px; flex:none; font-size:10px; color:#9aa2ad; padding-top:8px; letter-spacing:.4px">21 AUG<br>19:40</div>
    <div style="flex:1; border:1px solid #eef1f4; border-radius:6px; padding:8px; display:flex; align-items:center; gap:10px">
      <div style="flex:1">
        <div style="font-size:12px; color:#2b313c">Check-in submitted</div>
        <div style="font-size:9px; color:#9aa2ad; letter-spacing:.4px; margin-top:2px">Weekly check-in · for 21 AUG · Client</div>
      </div>
      <span class="wchip" style="background:#e6f2ea; color:#0c7a4e"><span style="font-size:10px">Answered</span></span>
    </div>
  </div>
  <div style="display:flex; gap:10px; align-items:flex-start; margin-bottom:8px">
    <div style="width:52px; flex:none; font-size:10px; color:#9aa2ad; padding-top:8px; letter-spacing:.4px">14 AUG<br>09:05</div>
    <div style="flex:1; border:1px solid #eef1f4; border-radius:6px; padding:8px; display:flex; align-items:center; gap:10px">
      <div style="flex:1">
        <div style="font-size:12px; color:#2b313c">Payment: installment 2 of 3 paid</div>
        <div style="font-size:9px; color:#9aa2ad; letter-spacing:.4px; margin-top:2px">Coaching, 3 months · EUR 150 · Jovana Martinović</div>
      </div>
      <span class="wchip" style="background:#e6f2ea; color:#0c7a4e"><span style="font-size:10px">Paid</span></span>
    </div>
  </div>
  <div style="display:flex; gap:10px; align-items:flex-start; margin-bottom:8px">
    <div style="width:52px; flex:none; font-size:10px; color:#9aa2ad; padding-top:8px; letter-spacing:.4px">02 AUG<br>11:30</div>
    <div style="flex:1; border:1px solid #eef1f4; border-radius:6px; padding:8px; display:flex; align-items:center; gap:10px">
      <div style="flex:1">
        <div style="font-size:12px; color:#2b313c">Stage: Onboarding to Acclimate</div>
        <div style="font-size:9px; color:#9aa2ad; letter-spacing:.4px; margin-top:2px">Automation: Lifecycle stages</div>
      </div>
      
    </div>
  </div>
</div>

Who did it

The second line of every row ends with who made the change:

• a person’s name: someone on your team, in the app;
• Client: the client did it themselves, for example a check-in;
• Automation: followed by its name, when one of your automations made the change;
• System: a scheduled job, for example a plan ending on its date or a payment marked past due;
• Imported: the line was rebuilt from older records when history recording began, in October 2026. Imported, approximate date means the exact moment was never stored, so the date is the best one Protocol has.

A client’s history may start with Stage when history began: the stage they were in when Protocol started recording. It is a starting point, not a change.

Filters and older history

The chips across the top narrow the stream to one kind: All, Programs, Check-ins, Payments, Emails, Stages, Labels. Nothing is hidden by default, so All is where it starts. The timeline shows the latest fifty lines; Load more at the bottom fetches the next fifty.

A payment’s chip says what happened to it: Paid, Pending, Past due, Failed, Refunded, Canceled or Ended. A failed or refunded payment is never shown as paid.

Opening one line

Click any line to see everything Protocol recorded about that change:

• Reason: when an automation made the change, the sentence it wrote about why, shown first. For example, why a client moved to a new stage or why a label went on, often with the client’s own words.
• By: who made it, and through which API key or agent connection when there was one.
• Details: every field stored with the change, such as the stage it moved from and to, the label, the plan, the amount, or the dates.
• Technical: the evidence key and the record ids, small at the bottom. Quote these when you ask us about a change.

Lines recorded before automations started sending their reasons, in October 2026, show everything except the reason.

When the line belongs to a record, the dialog has an Open button that takes you there:

• a plan line opens that plan,
• a check-in line opens the entry on the Tracking tab,
• a form line opens the answers,
• a payment line opens the client’s purchases on the Billing tab,
• an email line opens the delivery detail, described below.

The reason to keep everything together rather than in separate lists is that it explains itself. The reminder that bounced sits directly above the check-in that never arrived, and read in that order the two are one story with a cause you can fix.

When the tab has nothing to show, the card says Nothing recorded yet.

The cards beside it

Each of the other cards answers one narrower question, and each has its own line for when it is empty, so a blank card never leaves you wondering whether it failed to load.

Past programs: the plans that have finished

Past programs lists the plans that have ended, most recent first, with the date they ended and how long they ran. A plan lands here once it is Expired or its end date has passed. Empty: Nothing has ended yet.

The check-in archive: reading a check-in from months ago

The check-in archive is every check-in this client has submitted, newest first, with the measurements it carried. It is the same records the timeline shows under Check-ins, without the date gutter. This is where you go to read an old check-in: one from last month, or from three months ago, without scrolling the timeline past everything else that happened since. Empty: No check-ins submitted yet.

Weight

Weight draws one bar per recent check-in that recorded a weight, up to twelve, oldest on the left, with the reading count and the latest value above it. There is no colour coding and no second series: the shape is the information. Empty: No weight logged yet.

Training log

The training log summarises the last twelve weeks of logged sessions: how many sessions were completed with a completion rate beside them, the average session length against the total time trained, and the muscle groups trained most. Empty: No sessions logged in this window.

Form submissions

Form submissions lists what this client has actually filled in, newest first, with the form’s name and the date. Click one to read the answers. All in the card header opens the full list on the Tracking tab. Empty: Nothing submitted yet.

Emails is the delivery log, and it gets its own section below. Empty: Nothing sent yet.

What happened to the emails

This is the card most worth knowing about, because it answers a question nothing else in Protocol can: did the client actually receive it.

Each row is one message: the subject, when it was sent, and an outcome chip. Where the mail provider gave a reason for a failure, that reason takes the line under the subject, because it is the part you can act on.

The distinction between Sent and Delivered is the whole point of the card. The four outcomes at the bottom of that table all mean the same thing in practice: your client never saw a word of it.

Opening one message

Click any email row in the card, or Open on an email line in the timeline, and you get the trail for that one message: who it went to, who it came from, the provider’s error in full, and each event in the order it happened with a timestamp.

The event names and the reason text are the provider’s, not ours. Everywhere else Protocol translates them into plain outcomes, but here the raw wording is what lets somebody match this message against the records upstream.

If the trail says Nothing reported back yet, it has two possible causes and they mean opposite things: the message may be older than the point where Protocol started recording delivery events, or the provider may simply not have reported on it yet. A recent message with no events is worth checking again in a few minutes.

Using it

Two jobs bring most coaches here.

Chasing a client who has gone quiet. Filter the timeline to Emails. If the reminders are bouncing, the client is not ignoring you and no amount of escalation will help: fix the address on the Personal tab, or hand them a login code instead. See Form reminders and the check-in worklist for what is being sent and when.

Reconstructing a few months. Leave the filter on All and read down. Stages, plans, check-ins and payments in one column, with who did each, is the fastest way to see where a client’s momentum went, before a renewal conversation or a plan rebuild.

Related

• Client profiles for the rest of the record.
• Plan statuses, and what your client sees for why a plan is in Past programs.
• Client to-dos for what a client still owes you right now.