The Fix: The Five-Minute Delivery Protocol That Prevents the 'We Never Got It' Claim

The Void of the “Sent” Folder

The deadline is 5:00 PM. At 4:55 PM, you attach the final deliverables to an email. You press send. You leave the office, satisfied that the contract is fulfilled.

Monday morning arrives. The client is irate. “We missed our launch window because you did not deliver the assets.”

You open your laptop. You point to the “Sent” folder. “It is right here,” you say. The client checks their inbox. “We have nothing. Perhaps it went to spam. Perhaps the file was too large. Regardless, we do not have it, and you are responsible.”

Who is correct?

In the absence of a verified audit trail, the client is correct. In business, the burden of proof lies with the vendor. You cannot bill for work that resides in digital limbo.

The Ambiguity: The Unreliable Carrier

The fundamental error is trusting the transport layer. Email, Slack, and WeTransfer are carriers. They are not witnesses.

When you rely on a simple file transfer, you accept the following risks:

1. Silent Failure: Firewalls often strip zip files or large PDFs without notifying the sender.
2. The Wrong Recipient: You type “John” and autofill selects “John (Competitor).” You have now delivered the asset to the wrong party, and you have no way to retract it.
3. The Time-Zone Gap: You sent it at 5:00 PM your time. They claim it arrived too late. Without a unified server timestamp, the argument is subjective.

[Image of email server bounce error diagram]

Therefore, we must treat delivery as a transaction, not a broadcast.

The Record: The Five-Minute Protocol

To eliminate this liability, we implement a strict Delivery Protocol. It requires five minutes. It saves five weeks of arguing.

The protocol consists of three immutable steps:

Step 1: The Upload and Link Do not attach files. Upload the asset to a secure environment that supports logging (The Ledger). Generate a unique access link.

• Constraint: Set the link to expire in 7 days to force immediate action.

Step 2: The Notification Send the notification via the agreed channel (Email/Chat).

• Script: “The assets are available for review at [Link]. Access is logged for security purposes.”

Step 3: The Verification (The Critical Step) Do not close the ticket. Wait. Monitor the Ledger. Within minutes or hours, you will see an event:

Event: LINK_ACCESS IP: 192.0.2.44 (Client Office) Time: 17:02 UTC Action: DOWNLOAD_COMPLETE

Once this event appears, you take a screenshot or export the log entry. You attach this to your project close-out file.

[Image of access log showing timestamp and IP address]

Now, revisit the Monday morning scenario. The client says, “We never got it.” You reply, “The record shows that User ‘Sarah’ at your corporate IP address accessed and downloaded the full package at 5:02 PM on Friday. The delivery was successful.”

The argument evaporates. The focus shifts from your competence to their internal file management.

Consequently, the protocol converts a defenseless position into an unshakeable one. Do not assume delivery. Verify it.

FAQs

Is email delivery not legally sufficient?

It is often insufficient. Email servers filter attachments silently. Proving delivery requires forensic IT intervention, which is costly.

Does this require complex software?

It requires a disciplined process using standard secure link tools. The tool matters less than the verification log.

Why is a checklist necessary?

Memory fails under pressure. A checklist ensures the critical step of verification is never skipped.