Keep useful coaching service-delivery records
A customer asks which sessions remain. The coach remembers a reschedule, the calendar still shows the original appointment, and support sees an open ticket. A useful delivery record should help the next person answer without reconstructing the month from memory.
Use this coaching service delivery records checklist to connect what you promised with what actually happened: sessions held, access provided, customer requests and outstanding follow-up. The aim is an accurate operating history, including delays and mistakes.
If you are preparing your business for its first processing conversation, start with the coaching merchant account preparation guide. This guide picks up once a program is running.
Record events with a source and an owner
Give each customer enrollment a reference that connects the offer, order and payment reference to the delivery history. Use the payment provider’s transaction reference; the delivery ledger does not need card numbers or security codes.
For each event, capture the date and time zone, service involved, status, source record and staff owner. Separate the event date from the date someone entered it. A correction should explain what changed rather than silently replace an earlier entry.
Be specific about what each record shows:
- Scheduled: An appointment exists. Attendance is still unknown.
- Access enabled: An account can access the promised material. This does not establish that the customer opened it.
- Use observed: A system recorded an identifiable activity. A login alone does not establish completion of a course.
- Customer confirmed: A message supports the particular fact confirmed, such as a restored login. It does not establish satisfaction with the entire program.
Stripe’s evidence guidance identifies service dates, service documentation, digital activity logs and relevant customer communications as potential evidence, depending on the dispute. That is useful context for record design, not a universal evidence list for every provider. Stripe: Dispute reason code categories.
A fictional delivery ledger, from enrollment to close
The following example is invented. Customer C-104 buys four individual coaching sessions and portal access for August 1–31, 2026. It is a fixed package without automatic renewal. Order O-104 links to payment reference P-204 and the purchased offer version. All times use America/New_York.
The ledger points to source records kept in restricted systems. Its short summaries exclude the substance of private coaching discussions.
| Event | Source record | Customer confirmation | Access and delivery state | Owner and next action |
|---|---|---|---|---|
| Aug. 1, 09:00: enrollment and access invitation | Order O-104; offer version A; invitation log | Checkout acceptance recorded; no login confirmation | Access enabled through Aug. 31; four sessions scheduled | Operations checks invitation failures |
| Aug. 3, 14:00: first session held | Session S-01 attendance record | Customer replies to scheduling follow-up | One session delivered; portal enabled | Coach records attendance that day |
| Aug. 8, 08:20: customer reports login failure | Support ticket T-18 | Customer’s original request retained | Portal marked enabled, but customer reports it unusable | Support owns investigation; update due that afternoon |
| Aug. 8, 11:15: login problem resolved | T-18 resolution; access event reference | Customer confirms successful login at 11:40 | Access restored; interruption remains in history | Support closes ticket with resolution time |
| Aug. 9, 16:00: customer requests moving Aug. 10 session | Email E-22; calendar change history | Customer accepts Aug. 11 at 14:00 | Original appointment rescheduled; still one session delivered | Coordinator updates coach and calendar |
| Aug. 11, 14:00: replacement appointment held | Session S-02 attendance record | No separate customer reply recorded | Two sessions delivered; portal enabled | Coach links this event to E-22 |
| Aug. 17, 14:00: customer does not attend | Session S-03 attendance record; follow-up E-31 | Aug. 18 reply declines rebooking | Two delivered; one missed; one scheduled | Support records reply without marking missed session delivered |
| Aug. 24, 14:00: final scheduled session held | Session S-04 attendance record | Customer acknowledges final-session follow-up | Three delivered; one missed; portal enabled | Coach sends completion summary; support handles questions |
| Aug. 31, 23:59: scheduled portal access ends | Access-state history; closing notice E-40 | Notice sent; receipt not confirmed | Portal access ended; no open support tickets | Operations checks closure against the purchased access period |
The closing summary is three sessions delivered, one missed, and portal access ended after a documented interruption. It is not “four sessions completed.” The missed appointment’s payment or refund treatment requires a separate review of the circumstances and applicable terms.
Before copying this layout, answer three handling questions: Can the assigned staff retrieve each source? Does the summary contain unnecessary personal detail? Who reviews the retention or deletion date for each record type?
For a processing conversation, use an anonymized example to explain how charges relate to delivery. Discuss your delivery model with NUMUS.
A coaching service delivery records checklist
- Connect the enrollment. Link the purchased offer and access period to the customer’s order and payment reference. Keep later changes distinguishable from the original commitment.
- Log actual session outcomes. Record held, rescheduled, missed or canceled. Link a replacement appointment to the original so it is not counted twice.
- Check access exceptions. Keep the customer’s report alongside the system status. “Enabled” is not a reason to dismiss a login failure.
- Assign the next step. Every unresolved request needs a responsible person, a next action and an update date. A coach’s completion note should not automatically close a support complaint.
- Reconcile the week. Compare upcoming appointments, completed sessions, open tickets and promised access periods. Investigate missing or contradictory entries; mark unresolved facts as unknown.
- Close with a factual summary. Count delivered and undelivered services separately, confirm remaining commitments, and record unresolved customer requests before treating the enrollment as complete.
When a customer asks to cancel or receive a refund, retain the request and link the resulting decision back to this history. The coaching cancellation and refund process covers the handoff between customer support, payment action and remaining services.
Keep the record useful without keeping everything
Use the ledger as an index, with sensitive source material restricted to people who need it. Session dates and attendance can often explain delivery without a recording, transcript or detailed account of personal goals. Do not collect additional sensitive material simply to fill a template.
Set a written retention schedule by record type, identifying the business purpose, responsible owner, access controls and secure disposal process. Review applicable obligations with qualified advisers; this article does not prescribe a universal retention period. The FTC recommends limiting sensitive information to legitimate business needs, restricting staff access and documenting retention and disposal. FTC: Protecting Personal Information—A Guide for Business.
What if a payment is disputed?
First identify the issue and your provider’s response deadline and instructions. A claim about missing sessions requires different facts from a question about a refund. Use relevant source records to build a concise chronology; an internal summary is a finding aid, not a substitute for the underlying record.
Records do not guarantee a successful dispute response. Stripe’s guidance recommends relevant, chronological evidence and explains that Stripe does not control the bank’s ultimate decision. Follow your own provider’s requirements for the specific case. Stripe: Dispute evidence best practices.
Keep dispute reporting separate from delivery completion. For questions about reported percentages, use the chargeback ratio calculation and provider questions guide.
The next person should be able to follow the story
A useful ledger lets staff locate the source, distinguish completed work from remaining commitments, and see who owes the customer an answer. Start with one current enrollment and check whether those facts are clear.
Explore NUMUS processing for coaching businesses for the broader account discussion. Bring your delivery model and an anonymized example, then discuss your delivery model with NUMUS.