Submitted, Accepted, Filed: A Simple Handoff Model for Operations Teams

Most file handoffs fail in the same quiet way. A crew sends the day's work in, someone at the office opens it to take a look, and then it sits. Nobody decided to drop it. There was just never a moment where responsibility clearly moved from one person to another, so it stayed with everybody and therefore with nobody. The fix is not a new tool or a longer checklist. It is a shared vocabulary for where a file is and who owns it right now.

This is that vocabulary: three states, called Submitted, Accepted, and Filed. It is a plain model any operations team can adopt on top of whatever storage or email they already use. The whole point is to make who is responsible for a file at each moment obvious, so that a packet can never quietly belong to no one. You do not need special software to think this way, though software helps you enforce it.

The model at a glance

A packet, meaning a set of files plus enough context to act on them, is always in exactly one of three states. It moves forward when a specific person does a specific thing, never on its own. Read the diagram top to bottom.

Submitted: it arrived, and the submitter still owns it

A packet is Submitted when its files have been uploaded in full and verified, and a receipt exists that both sides can point to. Verification matters here. “I sent it” is not the same as “it arrived whole,” and a handoff model that counts a packet as submitted before the last byte lands will let half-transferred work masquerade as complete. So the entry test for this state is concrete: every file is present, none is truncated, and there is a numbered receipt recording what came in and when.

The part teams skip is ownership. In this state the submitter, the person in the field, is still responsible. The office has a copy it can read, but reading is not receiving. If the packet is wrong, incomplete, or never gets picked up, that is still the submitter's problem to chase, because no one else has agreed to carry it. Keeping ownership with the submitter through this stage is what stops the classic failure where a file is technically “in the system” but nobody feels answerable for it.

Accepted: one person takes it, by name

Accepted is the state that makes the whole model work, because it is the only point where responsibility actually changes hands. A named person at the office accepts the packet, and from that instant they own it. Not the team, not the shared inbox, not whoever happens to look next. One name.

This distinction sounds pedantic until you have watched a packet fall through the gap between “I looked at it” and “I've got it.” When any view or download silently counts as taking the work, ownership becomes ambiguous the moment two people glance at the same packet. When acceptance is a separate, explicit act, there is always exactly one answer to “whose is this?” and it has a name attached. That single rule is most of what separates a tracked handoff from the email version everyone already has, where forwarding a message is the closest thing to a transfer and it proves nothing.

Filed: the work is closed, the record is kept

A packet is Filed when its files have reached their final destination, the job of moving them is done, and there is nothing left for anyone to do with it. This is the state that lets a queue actually empty. Without an explicit end, packets accumulate in a vague “probably handled” limbo, and you lose the ability to tell finished work from work that only looks finished.

Filing should also be the moment a durable copy is set aside. The version of the files that arrived, unedited and matched to the receipt, is what settles a question two years later when the working copies have been moved, renamed, or cleaned up under a retention rule. Closing the packet and retaining that archive are two halves of the same act: the live work moves on, and the record of what was handed off stays put.

What makes the model work

Three states is not the clever part. Plenty of teams have a rough notion of sent, received, and done. The model earns its keep because of the rules that sit under the labels. If you adopt only these, you have most of the benefit:

• Exactly one owner at each state. There is always a single person or a single clear status answerable for the packet, never a shared responsibility that is really no responsibility.
• Transitions are deliberate and logged. A packet moves forward because a named person chose to move it, and each move records who did it and when. Nothing advances by accident or by a side effect like opening a file.
• Reading never transfers ownership. Viewing, downloading, and forwarding are all safe to do. None of them changes who owns the work, so people can inspect a packet without accidentally becoming responsible for it, or dodging it.
• Unfinished work stays visible. Anything not yet Filed is still in the queue, plainly aging, where the office can see it. Nothing hides in a folder or a thread until someone remembers to ask.
• Each state has a definition of done. A packet is not Submitted until its files verify, not Accepted until a name is on it, and not Filed until it has reached its destination and been archived.

How to adopt it

You can put this model in place without changing your storage. What you are really deciding is what each transition requires and who owns the packet in between. Write those two things down and enforce them, and the labels take care of themselves.

Define what each transition requires

Give each arrow in the diagram an entry test, so a packet can only advance when the test passes:

1. Nothing to Submitted: all files uploaded and verified as complete, plus a short cover note saying what this is and which job it belongs to. On success, a receipt is created and the submitter is recorded as owner.
2. Submitted to Accepted: a specific office person clicks accept, or otherwise signs their name to it. Their name and the time are logged. Ownership now belongs to them and to them alone.
3. Accepted to Filed: the files are in their final home, the accepting owner confirms the work is complete, and a write-once copy is retained. The packet leaves the active queue.

Decide who owns each state

Ownership is not a job title, it is whoever is answerable for the packet right now. In Submitted, that is the field submitter. In Accepted, it is the single office person who took it. In Filed, the packet is closed, so ownership converts into a retained record rather than a person to chase. The transitions between those owners are the only places responsibility moves, which is exactly why each one has to be deliberate and logged. If you want the mechanics of making those moves stick across a busy intake, the same principles show up in the design choices that build accountability into intake, from a single front door for packets to a visible aging queue.

Write it down before you roll it out

A model in your head is not a model your crews follow. The step that makes this real is writing it into a short standard procedure: the three states, the entry test for each transition, and the one owner at each stage, in language your people recognize. Teams that skip this end up with three different interpretations of what “accepted” means, which is worse than having no model at all. Start from a template, adapt the owners and destinations to your firm, and keep it to a page. The Submitted, Accepted, Filed model is small enough that the written version can be short and still complete, which is the best guarantee that people will actually read it and do it the same way every time.