A person should be entered once, not sixteen times
Every sheet on a production carries the same phone number. Change it in one place and five are now quietly wrong. The fix is not discipline — it is deciding which copy is the real one.
Count the documents on a mid-size production that contain a given crew member's phone number. The crew list. The movement order. The rooming list. The emergency contact sheet. The catering count, indirectly, through their dietary restriction. The call sheet if you produce one. The WhatsApp group, which is a document whether you think of it that way or not.
Now change the number. One of those is updated. The rest are now lying, quietly, to whoever reads them next — and nothing on any screen indicates which is which.
The problem is not duplication. It is ambiguity
Duplication on its own is harmless. Photocopies are duplicates and nobody worries about photocopies, because a photocopy is obviously a copy. The problem on a production is that every copy looks equally authoritative. Six documents, six phone numbers, no way to tell which one was updated last except by asking the person whose number it is.
So the coordinator becomes a human router. Half of the job becomes forwarding, CC'ing, chasing, confirming receipt, and answering the same question several hundred times per production: is this the latest? Folder naming conventions are not an answer to that question. They are a way of pretending the question was not asked.
One master, and imports from it
The structural fix is to decide, explicitly, that one record is the person and everything else is a view of that record. On a production company that means an organisation-level crew database: a person is entered once there, and lands on a project by being imported, not by being typed onto a sheet.
That single decision has a consequence people underestimate. If import is the only path onto a project, then being on a sheet is the assignment — the roster and the document stop being two things that have to agree. Remove someone's last row and they are no longer assigned. There is nothing to reconcile because there was never a second list.
It also means that the third job you run with the same gaffer starts with the gaffer already there, with the correct spelling of their name, their ID on file, and their dietary restriction attached. Most production companies rebuild that knowledge every project and then lose it at wrap. It is the single largest piece of unclaimed value in a service company's operation.
Two kinds of fact live in the same row
Here is the part that is genuinely hard to design, and where most attempts fail.
Some facts about a person belong to the master record: their legal name, their passport, their bank details, a severe allergy. Those are true regardless of which production they are on, and they should be editable in exactly one place. Other facts are local to this job: their position on this shoot, which department they sit in, whether they are on the sheet at all.
Both appear in the same row on the same screen. If the interface does not make it obvious which is which, people edit the wrong copy — they correct a phone number locally, on this sheet, and the master stays wrong, and the next production inherits the error. A field that is owned by the master has to look owned by the master, and there has to be a deliberate motion to promote a local correction upward.
The vocabulary is load-bearing
A small point that turns out to matter. On a production, a section is a department, a row is a person, and their position is their role. Those words are not interchangeable with the software industry's words for the same shapes, and renaming them in the interface — groups, records, titles — quietly tells an experienced coordinator that the tool was not built by anyone who has done this.
The data model should be loose for the same reason. Department names are free text, bilingual, accented, and often long, because real crews do not fit a fixed schema. A dropdown of approved department names is a tool arguing with a production about what departments exist.
Design for hundreds, not for the demo
Finally: crews run to hundreds. Not the exceptional job — the normal one, once you count local crew, extras wrangling and vendors. Sections that collapse, documents that paginate with continued headers, attendance grids that group by department: these are the primary case, not the edge case. Any tool that is pleasant with twelve people and unusable with two hundred has been designed against the wrong production.