The Material Exists. Nobody Opens It.
A service business does not have a content problem. It has a hundred finished jobs, most of them photographed by a technician who was proud of the work that afternoon, and none of it is posted, because opening a closed job is nobody's assigned task. The photograph of the cleared main line is on a phone that is currently in a truck. The before and after of the compressor swap is attached to a job that was invoiced and forgotten. The sentence a customer said at the kitchen table, the one that would make the best opening line of the month, is in a technician's note that no office person has ever read. The writing was never the hard part. The hard part is that the material sits in a place nobody opens.
The reason it sits there is the first thing to fix and the least comfortable to say: a photograph taken on a customer's property is not the business's to publish. The business did the work, the business owns the invoice, and the business does not own the image of somebody's driveway, roof, or child's bicycle in the background. Permission has to be captured, and it has to be captured at the same moment as the photograph, because the alternative is the office driving back three weeks later to ask a customer whether a picture of a drain can go on a page. That conversation never happens. So the release is not a legal afterthought bolted to the end of a content process. It is the first field on the screen that saves the photo, and if it is not there, the photo is not published. Ever.
The second thing to fix is the assumption that a job photo is a post. A photo proves that work happened, which is exactly what makes it useful and exactly why it is boring on its own. A photograph of a replaced compressor is evidence, and it means nothing to a stranger who does not know what a compressor does. A post has to say something a stranger cares about, and the raw material for that sentence lives in the same record: the problem the technician wrote down, the parts that were replaced, the service that was performed. The best source for a month of posts is therefore the completed job record with its before and after and its parts list, because everything in it is specific to one address on one day, and specific is the only thing a local audience responds to.
Two honest limits finish the picture. The first is that any workflow which needs a person to approve every item is abandoned by the third busy week. That is not a theory about human nature, it is a count: week one is calm, week two has a backlog, and week three arrives with two techs out and a phone that will not stop, and the approval queue is the first thing to be ignored because it is the only task with no customer waiting on the other end. A workflow that assumes a diligent approver every day is a workflow with a three week lifespan. The second limit is that posting the same five photographs on rotation is worse than posting nothing at all. A feed built from a handful of assets teaches the audience that there is nothing new here and reads as automated even when a person approved every post, and that is a worse result than a quiet feed that shows up with a real job when one actually happens.
The reframe
Publishing from jobs is a consent problem before it is a content problem: capture the release with the photo, draft from the closed record, and let a queue with deadlines carry the approval a busy week will otherwise abandon.
What a Month of Job Material Actually Allows
Set the sliders to match your shop. The model separates the jobs that produced a photo from the jobs that produced a photo the business is allowed to publish, then compares the office time a manual pass takes against a system that drafts from the closed record and routes a short review.
Posts a month of records supports
13
of 32 jobs that produced a photo
Photos with no release on file
19
real work, and not the business's to publish
Office hours returned per month
7.2
10.2 manual against 3.0 drafted from the record
Clear rate
41%
of photographed jobs carry a usable release
Approval load
1.1
hours per month, the part a person still owns
What becomes of a month of job material
release stored on the job record, at the same step as the photo
The photo and the permission arrived together, on the same visit, by the same person. This is the only bucket where a post can be published without somebody going back to ask. It is also the smallest bucket in most shops, because almost nobody captures the release at the moment the photograph is taken.
photo exists, permission does not exist anywhere
The technician took a good before and after and nobody asked. The material is real work and it is not the business's to publish, so the honest outcome is that it stays in the record. A system that cannot see this bucket will publish from it, which is the failure a scheduler causes most often.
completed job, attached media, nobody looked
The job closed, the photos were filed, and no human ever reopened it. The bottleneck was never writing ability. It was that opening a finished job is nobody's assigned task, and an unassigned task does not happen.
queued with no deadline, still queued next month
The draft was fine and it sat in a review queue while the owner was on a roof. Any workflow that needs a person to approve every single item is abandoned by the third busy week, so a queue with no deadline is a folder, and a folder is where job content expires quietly.
asset reused past its cooldown with nothing new behind it
The business has five good photographs and cycles them. Posting the same five on rotation is worse than posting nothing, because the audience learns that this feed has nothing new to say, and it reads as automated even when a person pressed the button.
The five buckets sum to every finished job by construction, so the bars always reconcile. Only the first is gold, because only the first had permission captured beside the photo. The other four are the ways job material is lost after the photograph was already taken.
Illustrative estimate from the inputs above. Your own numbers will differ; this is not a measured result or client data.
The System, Stage by Stage
Six stages from capturing a release beside a photograph to keeping rotation out of the feed. Each names the system it touches, the payload it leaves behind, and the concrete way a naive implementation breaks.
Target System
The capture step and the job record
Capture the Release With the Photo
The permission has to arrive at the same moment as the photograph or it is never captured. Nobody drives back to a customer's house three weeks later to ask whether a picture of a cleared drain can go on a page. So the release is a field on the same screen that saves the photo, the technician asks while the work is still being admired, and the answer is written to the job record rather than to a shared drive nobody reads. A photo with no release stored beside it is treated as unusable, and the system says so instead of publishing it and hoping.
The release is a separate step for the office to chase later, so it is captured for the jobs nobody worried about and skipped for the ones that turned out to be the best photos.
Stage payload
What It Does Alone, With You, and Never
Reading a job record, catching a missing release, and drafting a sentence from the parts replaced are cheap and reversible. Publishing is neither, and an audience is watching. That line is what makes it safe to point a system at a live channel.
Autonomous
- Read completed job records and the media attached to them
- Capture the release on the same screen that saves the photo
- Treat a photo with no release beside it as unusable and flag it
- Order a job's photos into a before and after sequence
- Draft a post from the parts replaced and the problem the technician wrote down
- Queue every draft with a deadline and expire what passes it
- Read the publish result back and reconcile it against the queue
- Hold an asset inside its cooldown so nothing rotates
Supervised
- Approve every post before it publishes anywhere
- Decide which surfaces the business actually wants to run
- Approve the framing on any photo where a customer's property is visible
- Approve a caption that names a price, a warranty, or a customer
- Agree to retire a surface the log shows nobody engages with
Never
- Auto-post a customer photo with no captured release
- Republish a review verbatim without permission
- Run a content calendar with no source material behind it
- Publish the same handful of assets on rotation
- Publish a post no person approved
- Invent a job, a service, or a claim the record does not support
- State a limit, a dimension, or a metric that no source documents
Three Things We Will Tell You Not to Buy
Each of these is a normal line item in a social media proposal for a service business, and each of them is a reason the finished work never reaches an audience.
Auto-posting customer photos with no captured release
The photograph of a cleared drain, a new roof, or a customer's driveway belongs to the customer, not to the business that did the work. A release that gets captured at the same moment as the photo is a formality nobody notices. A release the office has to chase afterwards never happens, so the pipeline quietly publishes from the material that was never cleared. The system must treat a photo with no release beside it as unusable, and say so, rather than run at full speed and let the first complaint find the gap.
Republishing a review verbatim without permission
A review is a customer describing their own experience in their own words, and it is not the business's copy to lift onto a feed. Dropping a five star paragraph onto an image and posting it is a common tactic and it is a request the business has no right to grant on the customer's behalf. The honest move is to link to the review where it lives, or to write the business's own sentence about the same job, which is a different thing with different evidence behind it. The two systems stay separate.
A content calendar with no source material behind it
A calendar with slots and nothing behind them produces posts about the season, the weather, and why maintenance matters, which is what every competitor posts and what no reader in a service area needs. The calendar is downstream of the material. It can only hold what the completed jobs and their photographs can support, and on a month with little finished work the correct output is a shorter calendar, not a longer one with thinner posts. A schedule pointed at a target rather than at the record is the reason feeds look the way they do.
Questions About Posting From Jobs
Where This Fits in Marketing and Reputation
This page owns social publishing from finished jobs: the release, the surface, and the queue. The written content extracted from a job record is a different page, the profile is its own surface, and review requests belong to the pages built for them.
Find Out How Much Finished Work Never Reached an Audience
Give us read access to one system of record. In thirty minutes we will show you how many completed jobs last month produced a usable photograph, how many of those carry a release you could actually rely on, and how many of the same assets your feed has cycled through more than once. You keep the analysis whether or not you hire us.
