The picture, on the job it belongs to
Send a photo of the damaged bumper with the words that describe it, and the picture ends up on that job. Six weeks later, when somebody disputes what was there, it is still on the job rather than somewhere in a group chat.
A photo or PDF sent with a message is downloaded and kept. When the same message also creates a job, the photo is attached to it, so the picture of the damage sits on the job about the damage. Files are stored on your server beside the database rather than inside it, and the same photo sent twice is stored once.
- Kept
- JPEG, PNG, WebP, HEIC and PDF
- Attached to
- The job that message created
- Stored as
- Files on your server
- Duplicates
- Stored once
- Interpreted
- No - a person still looks at it
The picture somebody will ask for later
Damage on arrival
The scuff on the bumper when the car came in, on the recon job, before anybody argues about when it happened.
A reading or a label
The temperature display, the batch code, the serial number - photographed in a second, readable forever.
The finished work
Proof the job was actually done, attached to the job that says it was.
A short delivery
The pallet as it arrived, against the supplier problem it produced.
A document
A PDF invoice or certificate kept with the work it belongs to.
Found again
On the job, on the dashboard, next to its history - not by scrolling a year of chat.
What is accepted
- JPEG, PNG, WebP
- Yes
- HEIC, from iPhones
- Yes
- Yes
- Anything executable
- Refused
- Over 12 MB
- Refused
Files on disk, not inside the database
The whole backup story for this product is that your data is one file you can copy anywhere. A few hundred photos inside that file would double its size and quietly break the thing that makes it simple.
So photos are written beside the database and recorded in it. The backup script takes both. The name on disk comes from the contents, so the same picture forwarded round a team five times is stored once and deleting one copy never takes another job's evidence with it.
- The database stays small enough to copy, which is the whole backup story
- The same photo sent twice is one file, two records
- Deleting one record only removes the file when nothing else points at it
- Only formats a business actually sends are accepted - nothing executable
- Anything over 12 MB is refused rather than stored
It keeps the photo. It does not read it
The assistant does not look at what is in the picture. It will not read a temperature off a display, recognise a part, or judge whether the work is finished. A person still does that.
That is a deliberate line for now. Describing a photo confidently and wrongly - "the reading shows 4 degrees" when it shows 14 - would be worse than not describing it at all, and this product would rather keep the evidence than guess at it.
- The photo is kept, attached and findable
- The words you send with it are what create and describe the job
- Nothing is inferred from the image itself
- If reading photos is what your business needs, tell us - it is a real thing to build, not a thing to fake
More of the assistant
On this page
What happens to a photo sent on its own?
It is kept, and the reply says so and asks what it is for. Send the words afterwards and the next job you create carries it. Nothing is thrown away just because it arrived without a caption.
How much space will this use?
A phone photo is one to three megabytes. A busy team sending twenty a week uses a few gigabytes a year, which is nothing on the hosting the rest of this runs on. The dashboard shows the running total.
Are the photos included in the backup?
Yes. The backup script takes the database, its encryption key and the attachments together, because a job list pointing at photos that were not backed up is worse than either alone.
Can I delete one?
Yes, from the dashboard. The file itself is only removed once no other record points at it, so deleting a duplicate never takes another job's evidence.