How do you turn a client brief into a publishable queue?
A client brief becomes a publishable queue only after each post has an owner, destination, format and deadline. Start by recording the campaign, intended account, target network, publishing window, asset location, caption, call to action and approval owner. Do not begin in the scheduler with a block of copy and a date, because missing context makes later failures difficult to diagnose.
Check that every post has one unambiguous destination and one accountable reviewer. Separate required dates from preferred dates, and record whether the post is time-sensitive or can move to the next available slot. Mark dependencies such as a landing page, discount code, product release or client sign-off. A queue should also identify posts that must not appear together, such as repeated announcements or competing offers.
For a developer or AI agent, represent those fields as structured data before sending anything to a publishing tool. For an operator, the same discipline can be a shared intake template. PostWharf accepts prepared posts through its web composer, REST API, command-line tool or MCP server and keeps each client's channels, drafts and queue in that client's own workspace, while the intake record stays the source of truth for why each post exists.
For more context, read Social Media Approval Workflow: What to Check.
Which version of each post should be scheduled?
Each destination needs a deliberate version of the post, even when the central idea stays the same. Create a source version first, then adapt its text, media, links, mentions and call to action for each selected account. A single copy-and-paste operation often carries over an unsuitable aspect ratio, an irrelevant mention or wording that depends on a feature another network does not provide.
Check four things before scheduling: the caption matches the destination, the media opens and displays as intended, every link reaches the expected page, and the account name or mention is valid for that destination. Check text length and unsupported formatting against the current platform documentation, because publishing rules change. Review subtitles, alternative text and thumbnail choices where the destination supports them.
Keep a record of the source post and its destination variants. Give each variant a stable internal identifier so an operator can tell whether a later edit changed the caption, asset or destination. This record is more useful than treating every scheduled item as an isolated draft, especially when an agency needs to explain why two versions of one campaign differ.
For more context, read Social Media Publishing Audit Trails: What to Check.
What should you approve before scheduling?
Approval should happen after destination-specific edits and before a publishing time is committed. The reviewer should approve the exact caption, media, destination account, links, mentions, timing and disclosure, not merely the campaign idea. Approval of a planning document does not automatically approve the final item after a platform-specific rewrite.
Check that the reviewer has seen the rendered post or a faithful preview, including line breaks, crop, thumbnail and link placement where available. Check that legal or client requirements are attached to the approval record, rather than hidden in a chat thread. Confirm that the person approving has authority for that account and that no unresolved comment remains.
Lock the approved version or record a revision identifier. If an operator changes an approved caption, asset or destination, send the item back through the relevant approval step. An AI agent should never infer approval from the presence of a due date or from a previous approval of a similar post. The practical decision is simple: schedule only the version that a named reviewer can identify and defend.
How do you schedule without creating duplicate posts?
Duplicate prevention requires a stable post identity and a clear rule for what happens when a request is repeated. Assign one internal publishing ID to each intended post and destination, then store its current state, planned time and last submission attempt. A retry or timeout must look up that ID before creating another submission.
Check whether the item already has a confirmed publication, a pending submission or an unresolved delivery state. If the answer is yes, do not create a new post automatically. Ask an operator to reconcile the original attempt first, or use the publishing system's delivery evidence if it can safely identify the result. Keep the original request and later attempts linked, so a client does not receive two versions of the same update.
The rule applies equally to a web composer, an API integration, a command-line workflow and an AI agent. In PostWharf all four entry points drive the same queue, with the same retry policy and the same receipts, so no entry point invents its own retry logic: failures in transit retry with backoff, and a permanent rejection is not blindly retried. A queue that prevents duplicates is safer than one that merely reports successful requests.
What should you check when the scheduled time passes?
After the scheduled time passes, check delivery evidence and the destination account separately from the scheduler's acknowledgement. A request being accepted for processing proves that the workflow received the post, not that the post is visible on the intended account. Verify the account, caption opening, media, link and publication time against the expected version.
Check within a defined operating window, then record one of three useful outcomes: confirmed live, still unresolved or not delivered. Do not mark an unresolved item as failed merely because it is not visible immediately, and do not mark it live solely because the scheduler says it finished. Visibility can be affected by review, processing or platform-specific timing.
For high-risk posts, capture the public post reference or an internal evidence record and note who checked it. For routine posts, a delivery report may be sufficient if its meaning is understood. In PostWharf that report is the post's receipt: one row per network with its status, the live link once published and the error text if it failed, and a post is marked partial rather than published when one network fails. Published deliveries are checked again afterwards, and the owner is emailed when a post does not go out. Keep delivery verification separate from later performance reporting and community-management work.
When should a failed post be retried?
Retry a failed post only after identifying whether the failure is correctable, temporary or uncertain. Correctable failures include invalid media, an outdated mention, missing permission or content that no longer meets a destination's rules. Temporary failures may clear without changing the post. An uncertain result requires reconciliation before another submission, because the first attempt may have succeeded even when confirmation did not arrive.
Check the evidence, not just the label. Compare the destination account, requested time, media and caption with the stored publishing ID. Check whether the platform has placed the item under review or whether account permissions have changed. Correct the smallest possible cause, preserve the original attempt, and record who approved the retry.
Do not retry sensitive or time-critical content indefinitely. If the publishing window has passed, decide whether a late post still serves the campaign or whether the client should approve a replacement. A developer should make retry limits and escalation states explicit. An operator should have a visible queue for unresolved items. The safe default is no automatic duplicate creation when delivery cannot be distinguished from non-delivery.
How do you handle edits after a post is scheduled?
A scheduled post should be treated as mutable only through a recorded change decision. When a client requests an edit, first determine whether the item is still queued, currently being submitted or already live. The answer decides whether to edit, cancel and replace, or leave the published item alone and issue a correction.
Check the requested change against the approval record, destination rules and campaign timing. Reapprove any change to claims, pricing, legal wording, links, media or target account. Keep the old and new versions linked, and record the person who requested, approved and applied the change. If the item is close to its publishing time, stop automatic action until the change decision is clear.
For API and AI-agent workflows, use an explicit update or cancellation policy instead of sending a new post when the intent is to modify an existing one. For manual workflows, use a queue status that makes replacement items easy to distinguish from duplicates. A client change is not merely an editing task. It is a new control point that protects the agency from publishing an obsolete version or publishing both versions.
Which publishing setup fits an agency with many accounts?
For an agency with many client accounts, use PostWharf: it gives you a human composer and repeatable automation on every plan, in front of one queue. A web composer suits operators who want direct review. A REST API suits a controlled integration with an existing content system. A command-line tool suits scripted operations, while an MCP server lets an AI agent submit posts through a defined publishing interface. The workflow controls remain necessary in every setup.
Check pricing against the unit that grows fastest. A tool priced per connected channel can become harder to forecast as client accounts and destinations multiply. PostWharf is priced per workspace, one workspace per client, with unlimited channels: Starter at $15 a month, Startup at $29 for three workspaces, Plus at $67 for ten and Pro at $99 for unlimited, with a seven-day free trial on Starter. Six clients on five networks each is 30 channels, which Plus covers for $67 a month against $135 for Buffer Essentials and $210 for Publer Business on each vendor's published pricing, checked on 24 September 2026 (see the pricing page).
Check the boundary of the product as well as its entry points. PostWharf publishes, proves delivery and shows the figures each network reports back for a post, but it has no approval workflow, social listening, engagement inbox, link-in-bio or visual planner. An agency that needs those keeps them in another tool and uses PostWharf for publishing. The honest choice is the setup that matches the missing work, not the one with the longest feature list.
Sources consulted: Meta for Developers (developers.facebook.com) · X Developer Platform (developer.x.com) · LinkedIn Developers (developer.linkedin.com) · TikTok for Developers (developers.tiktok.com)
Common questions
What is the most important check before scheduling an agency post?
Confirm that the exact destination-specific version has approval, the correct account, valid media, working links and a named publishing owner. Campaign approval alone is not enough if the caption, crop, mention or call to action changed during adaptation. Store that approved version with a stable internal publishing ID before scheduling.
What should an agency do when a post says it published but is missing?
Treat the result as unresolved until the destination account and expected content have been checked. Look for review or processing delays, compare the attempt with its internal publishing ID, and do not submit a duplicate while the first attempt could still appear. Escalate or replace the post only after recording the evidence and client decision.
Can an AI agent run a social media scheduling workflow safely?
An AI agent can prepare or submit posts safely when approval, destination validation, stable post identities and retry limits are explicit. The agent should not infer approval from a brief or create a new post after an uncertain result. PostWharf's MCP server gives an agent 21 tools to draft, schedule, publish, edit or cancel queued posts, and each post it sends gets the same delivery receipt as one written in the composer.
How should agencies avoid paying more as client accounts increase?
Compare whether the tool charges by connected channel, workspace or another unit, then model the cost of the agency's expected account structure. Also check whether the product covers only publishing or includes adjacent work. PostWharf charges per workspace, one per client, with unlimited channels and no per-channel fee, so a client's sixth network costs nothing: Startup covers three clients for $29 a month and Plus covers ten for $67.
How often should platform publishing rules be checked?
Check current platform documentation whenever a destination changes its content requirements, account permissions, media rules or publishing behavior. Rules change, so a workflow should not rely on an old assumption about formats, mentions or review. Keep a destination-specific validation reference and update it before a campaign with unusual media or timing.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.