Photos and files from the job — findable a year later
A photo sent to a group chat stops existing once the thread scrolls. How to attach files to the job so they can still be found a year later, not just today.
An engineer photographs a distribution board before rewiring it and posts the picture to the group chat. Someone replies "ok". By evening there are two photos from another site; by Friday the thread is about Monday's schedule.
A year on, when the customer disputes what state that board was in, nobody finds the photo. Finding it means knowing the day it was taken — and the question is not about a day. It is about a board.
A chat is a medium, not an archive
A conversation has one axis: time. Everything dropped into it is ordered by the moment it was sent, and by nothing else.
The questions people ask months later have no time axis. "What did we do at this address." "What did the board look like before the swap." Neither starts with a date, and a date is the only thing a chat reliably knows about an attachment.
The file itself arrives with nothing the business needs: whose job, which site, which stage of the work all live in the surrounding messages, and those will soon be about something else. Nothing is deleted; it just stops being reachable.
What the file is attached to
This is the whole decision; everything else follows.
To a conversation. Findable as long as somebody remembers roughly when it came up — which is to say, until the thread scrolls past it.
To the job. The file has a place it always sits in, and whoever opens the job sees the full set.
To the asset. With the job linked to a specific unit, site history builds itself as a by-product of closing jobs.
Better still, go one level down. Fourteen photos in a bucket on the job beat a chat thread and are still not documentation; one attached to the line "circulation pump replaced" answers by where it sits.
The link has to be made when the shutter goes. The camera writes metadata of its own — a time, sometimes a location — the one axis nobody searches on. What it cannot know is which line of which job someone was standing at. Filled in that evening, that is a reconstruction from memory rather than a record — and with two similar sites in one day, sometimes the wrong one. The screen side of this is what field technicians need in an app.
Losing signal changes nothing here. The photo queues like any other write in offline mode for field teams, and because the link was made on the device, the sync carries it with the file.
Why version history earns its keep
A photo is taken once. A document changes several times, and that is where the trouble lives.
Quotes, as-built drawings, warranty certificates all have versions. In practice: "quote_2.pdf", "quote_2_revised.pdf", "quote_final.pdf", "quote_final_client.pdf". Four files, one thing, no information about which is in force.
Version history inverts the assumption: a document's identity is the slot it occupies, not its name. A new version takes the slot rather than landing beside the old one; the old one drops a level, with a date and an author. So whoever opens it lands on what is current, and nothing disappears, because replacing is not deleting. Otherwise being out of date has to be guessed at — the kind of guesswork that degrades the data whoever is using it, which is why preparing company data for AI starts with tidying like this, not with a model.
The sign-off: evidence has to know what it covers
A customer's signature is worth something only if you can point at what they signed. One drawn with a finger, saved as an image and posted to a chat, is a picture of a signature: it does not say what scope it confirmed, against which version of the sheet, or when. A year later it is material that has to be explained rather than one that explains.
A useful record attaches the signature to a specific version of the document, with a timestamp and the signer's name, and the document to the job — none of it extra work if done at handover. Paper makes none of those links and comes back late or not at all, one of the breaks examined in the piece on the service work order workflow.
Search by job, not by date
Take a job closed a year ago and assemble the set: photos before and after, the signed sheet, the quote version that was agreed. No phone calls, no scrolling a chat.
If it takes more than a minute, the problem is not tidiness but the axis you are searching on. A gallery and a chat archive answer what happened that day; you need what belongs to this job, and no sorting gets you there. Full-text search helps without replacing attachment: it finds the file that mentions the customer's name, not the photograph that mentions nothing.
Copies on personal phones
A photo from site is created, by default, in the gallery of a personal phone; the company's copy is secondary, when it exists. Nobody notices while the person is still there; you can ring them. It surfaces when they leave: years of documentation sit on a device the company does not own, and a request to someone who has just left is not a procedure.
The fix sits earlier than offboarding: the photo is taken from the job, not from the camera app. Then the company copy is first and the gallery copy incidental — not discipline, but which button is nearer.
What the system cannot see, a model cannot see either
An AI assistant connected to company data does not browse the gallery on an engineer's phone or the archive of a group chat; it reaches what the system exposes as data.
So "what did the installation look like before our last visit here" has an answer only if the photo is attached to the job and the job to the asset. One sitting in a conversation does not exist for the model — not because it is protected, but because nothing connects it to that address.
The same work serves both audiences: context recorded so a coordinator finds a photo on Friday is what lets a model find it a year later. Less comfortably, a model answers from what it finds, and will not mention that half the site's documentation went to a chat.
Summary
One decision settles the rest: what the file is attached to. To a conversation, and it goes when the conversation goes. To the job, and to a line within it, and it is there when needed — long after everyone has forgotten the detail.
Then version history instead of filenames ending in "final", a signature bound to a specific version of the document, and photos taken from inside the job so the company copy comes first. What else has to be true before a crew records anything is in the guide on managing field teams.
Frequently asked questions
- Where should photos from site be stored so they can be found a year later?
- Against the job, ideally against a specific line on the job, and recorded automatically at the moment the photo is taken. A phone gallery and a chat archive both organise files by time, whereas the questions asked months later are about a site and a scope of work, not a date.
- Why keep version history when you can just save a new file alongside?
- Because four files whose names end in final tell you nothing about which one is in force. Version history assumes a document's identity is the slot it occupies rather than its name — the new version takes that slot, the previous one drops a level with a date and an author, and nothing is lost.
- What about work photos sitting on a technician's personal phone?
- Make sure the company copy is the one created first, which means the photo is taken from inside the job rather than from the camera app. Recovering documentation from a personal device after someone leaves is not a procedure, it is a request, and it usually ends the way requests end.
Read next
Five views of the same job — map, table, kanban, timeline
The dispatcher wants a map, finance a table, the manager a timeline, the engineer today's list. What each of the five views is for, and what each one hides.
Offline work in the field — a real requirement or a convenient excuse
Three levels of working without a network and what each one costs. How to check whether your crews really lose signal, before full offline delays the rollout.
The service work order workflow — from first call to invoice
Six stages of a service work order and the three places information goes missing. What each stage must record so the next one does not start with a call.