The Post Is a Time Boxed Event, Not a Feed
Most profile post tools are built on a publishing metaphor borrowed from social media. There is a calendar, there are slots, and the software is judged on how reliably it fills them. That metaphor is wrong for this surface, and it produces the failure people actually complain about: a profile carrying months of notices that describe nothing.
A post on a business profile is closer to an announcement than to a feed item. It has a reason, it has a short life, and it competes for a reader who is trying to decide whether to call you. The API's own vocabulary reflects that. A post carries a topic type from a closed set, an optional event with its own start and end, an optional offer with a coupon code, an optional call to action whose button points at a link, and a state that reports where it is in its lifecycle.
The honest limit has to be stated plainly, because the entire commercial argument for this work is usually built on it and it does not exist. Google publishes no ranking or conversion effect for posts. Local results are described as mainly based on relevance, distance, and popularity, and Google states that there is no way to request or pay for a better local ranking. Nobody has a documented number for what a post is worth, and a system built on the promise of one is built on nothing.
So the automatable work is narrower and more interesting than publishing on a schedule. It is deciding what deserves a post, generating it from a real business event, checking every field against the constraints the API states, scheduling it against the time box the post itself carries, and refusing to publish when there is nothing to say.
The reframe
The trigger for a post is a record, not a date. If nothing in the business happened, the correct output of the system is no post, and the system should say so on purpose.
What Filler Costs, and What Refusing Saves
Move the sliders to match how you post today. The model separates the posts that have a real reason from the ones written to fill a slot, then compares the office time a manual calendar takes against a system that drafts from the record and routes a short review.
Posts with a real reason
of 12 planned this month
Posts written to fill a slot
65% of the calendar
Posts published per year at this pace
144
of which 96 carry no real event
Office hours recovered
10.8
per month, 13.0 manual against 2.2 drafted
Signal ratio
35%
of the calendar has a nameable reason
What becomes of a month of posts
A finished job, a season turning, an offer with a start and an end. The post has a reason that can be named, which means it can be written from the record rather than invented at the keyboard.
The most common failure, and the one an automation product is most likely to cause. A post written because the calendar had a slot is filler, and filler is the thing that teaches a reader to stop reading.
A draft that waits for a person who is on a roof. Without a review step that has a deadline, a good draft decays into a stale one and the event it described passes.
The API returns a rejected state for a content policy violation. A system that never reads the state back will keep counting a rejected post as a published one.
A coupon code with no end date is a promise the business did not mean to keep. The offer content is the part of a post that expires first, and it expires on a date the business chose.
An event post carries its own start and end. Scheduling the post after the start, or approving it after the end, publishes a notice for something that already happened.
The six buckets sum to all planned posts by construction, and only the first one is gold, because only the first one had a reason. The other five are the ways a post calendar goes wrong, and every one of them is preventable by a system that reads a record before it writes a sentence.
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 reading the record that justifies a post to reading the state back. Each names the system it touches, the payload it leaves behind, and the concrete way a naive implementation breaks.
Target System
The system of record: ServiceTitan, Jobber, Housecall Pro, Tekmetric
Decide What Deserves a Post
The trigger is an event that actually happened, and the event is already recorded somewhere the business trusts. A completed job with a photograph. A seasonal service coming due. An offer with a start and an end. The system reads that record and asks whether it is worth saying out loud, and the answer is allowed to be no.
The system starts from a calendar rather than a record, so it produces a post every day whether or not anything happened, and the profile fills with filler.
Stage payload
What the API Actually Requires
A system that submits posts learns the rules one rejection at a time unless somebody reads them first. The rules are documented and they are narrow. The topic type is a closed set of four values, and an alert post is explicitly not always available for authoring, so no workflow should depend on publishing one. A post with a call to action includes a button, the button text is determined by the action type, and a link to a user provided URL is added to the button. The action type set covers booking, ordering, shopping, learning more, signing up, and calling, and the older offer action type is deprecated in favor of the offer topic type.
Media is where the constraints get concrete. Only photos are supported in this version. Every photo must measure a minimum of 250 pixels on the short edge and carry a file size of at least 10240 bytes, with the profile and cover categories exempt from that minimum. The original source URL provided in the request is not retained in the response, which is the detail that catches people: the system must store its own reference to the asset rather than treat the submitted link as a durable address for the image.
Timing is the part that requires honesty rather than cleverness. The scheduled time is documented as determining when a post will be published and can be set in advance. The reference does not publish a fixed lifetime for a post, and it does not state what happens as one ages. An event post, by contrast, carries its own schedule with a start and an end. The practical consequence is that the only reliable time box in the data is the one the business set on the event or the offer, and everything else needs a review date the system owns.
Quota matters at scale. The Business Information API carries a default of 300 queries per minute, and edits are capped at 10 per minute per profile and cannot be increased. Exceeding a limit returns a 429. A monthly post calendar sits comfortably inside that, which is a useful signal about the shape of this work: the constraint on posting is not throughput, it is whether anything happened.
The contract in one line
What It Does Alone, With You, and Never
Reading and drafting are cheap and reversible. Publishing is neither. That line is what makes it safe to point a system at a live profile.
Autonomous
- Read the job, season, and offer records that could justify a post
- Decide that no post is warranted and record why
- Draft a summary from a recorded event rather than from a template
- Check the topic type, the call to action, and the media against the documented constraints
- Attach a photo that clears the minimum short edge and file size
- Set the scheduled time and date its own review
- Read the post state back and report a rejection
Supervised
- Propose the post for a person to approve before it publishes
- Propose the call to action type and the link it points at
- Propose the photo, drawn from the job the post describes
- Propose the publish slot against the event it references
Never
- Publish a post no person approved
- Invent an event, a discount, or a coupon code
- Author an alert post on its own
- Publish a post for no reason other than filling a calendar
- Claim a post improves local ranking or produces calls
- State an expiration date Google does not publish
- Retry a rejected post without changing what was rejected
What This Is Not
Not a content mill
A system that publishes daily because the calendar has a slot is not a system, it is a printer. The measure of this work is not volume. It is how many of the posts carry a reason a reader could name, and the correct number for a quiet month is zero.
Not a ranking lever
Google publishes no ranking or conversion effect for posts. Local results are described as mainly based on relevance, distance, and popularity, and there is no way to request or pay for a better local ranking. Anyone quoting you a post-driven lift is quoting something Google did not say.
Not the profile fact record
Hours, categories, service areas, and the drift sweep across every surface where those facts are copied belong to a different job. This page owns posts only: the topic types, the call to action, the media, the schedule, and the state read back.
Not general profile operations
Answering questions, managing attributes, and uploading photos as standing profile assets are operational work on the profile itself. This page uses a photo because a post needs one. It does not manage the photo library.
Questions About Automating Posts
Where This Fits in Marketing and Reputation
This page is the profile activity specialist. It defers the fact record and the drift sweep to local SEO automation, the pillar framing to marketing automation, and the general profile operations to their own page.
Find Out What in Your Business Deserves a Post
Give us read access to one system of record. In thirty minutes we will show you the completed jobs, seasonal services, and dated offers in the last month that could have carried a post, and how many of your last twelve posts had a reason a reader could name. You keep the analysis whether or not you hire us.
