Why Your Social Tools Do Not Talk to Each Other.

Only 36% of marketers say their current stack is very cohesive or fully integrated across workflows.

That number comes from HubSpot’s 2026 Social Media Marketing Report, which surveyed more than 1,100 social media professionals, and it usually gets read as a software problem.

It is not a software problem. The other 64% are not short of tools.

They are short of handoffs that hold. The brief lives in one place, the assets in another, the captions in a third, sign-off in email or a chat thread, the schedule in a publishing tool and the numbers in a spreadsheet. Nothing in that list is broken.

But every gap between two of those places is a person copying something across by hand, and that is where the process actually fails. Tool sprawl is not a licensing question. It is a handoff question.

The instinct is to go looking for one platform that holds all six. The cheaper fix is almost always deciding which system is the source of truth for the calendar, the assets and the sign-off, then making everything else read from those three.

The re-typing tax

Every manual handoff costs three things: time, accuracy and accountability.

Time is the obvious one and the least important. The real damage is that a re-typed thing can be wrong, and a re-typed thing carries no history. When a caption is pasted from a doc into a scheduler, the scheduler has no idea what version it was approved against.

Asana’s Anatomy of Work research puts the average worker switching between nine apps a day, with 56% saying they feel they have to respond to notifications immediately. Okta’s Businesses at Work 2025 report found the average company now runs 101 apps.

Social teams sit at the sharp end of both figures, because social work is almost entirely handoffs. This is why we argue that social should run as a system rather than a calendar: the calendar is only one artefact among six, and the joins between them decide whether the week ships.

Seam one: brief to asset

What breaks: the shoot or the edit answers a version of the brief that has since changed.

The symptom is assets that are technically good and strategically wrong. Someone says “that is not what we asked for”, and nobody can produce the version that was asked for.

The cause is that the brief was written in a doc, discussed on a call, amended in a chat thread, and never rewritten anywhere.

The fix is one brief record per piece of work, amended in place, with the date of the last change visible on it. If something changes on a call, the call ends with someone editing the record. Verbal amendments do not exist.

Seam two: asset to caption

What breaks: the caption is written against the wrong cut, the wrong crop or the wrong version of the file.

This is the most common failure in busy teams and the most public one. A writer opens the folder, finds v2, writes to it, and v4 is what goes out. The caption references a shot that is no longer in the edit.

In the same HubSpot survey, 45% of marketers say consistently producing high quality content is their top challenge. Some of that is talent and time. A quieter part of it is that the good version existed and the wrong version shipped.

The fix is that version numbers on filenames are not enough. The caption should attach to the asset rather than sit next to it. If your tools cannot do that, make the asset library the source of truth and have the caption record the asset ID it was written against.

Seam three: caption to approval

What breaks: approval happens against a screenshot, a pasted block of text or a chat message, so nobody can prove afterwards what was signed off.

You know this seam by the argument it produces. “I approved that.” “No, you approved the earlier one.”

There is a second version of the same failure: approvals that arrive as commentary rather than decisions. “Looks good, though maybe shorten the second line” is not an approval, and treating it as one is how half-agreed copy gets scheduled.

The fix is that approval attaches to a specific version and produces a binary outcome with a name and a timestamp on it. Anything else is feedback, and feedback is a different step in the process.

Seam four: approval to schedule

What breaks: the approved version and the scheduled version drift apart after sign-off.

The sequence is familiar. Caption approved. Someone spots a typo. They fix it directly in the scheduler. The fix quietly reintroduces a phrase that legal asked to remove three days earlier, and no record exists of either change.

The fix is that nothing enters the scheduler except approved copy, and edits made inside the scheduler are either banned outright or logged somewhere the approver sees.

If the scheduler is the only place a caption exists after approval, it has become your source of truth by accident. It is a poor one, because most publishing tools keep no version history worth reading.

Seam five: schedule to report

What breaks: the report counts what published, not what was planned, so nobody can tell the difference between a plan that failed and a plan that never shipped.

Only 37% of marketers in the HubSpot survey say it is easy to tie social activity to business outcomes, and 41% of B2B marketers say it is hard. Some of that is genuinely difficult attribution.

A lot of it is simpler than that. The reporting layer never received the intent. If the calendar knows a post was pillar three, aimed at retention, and the report only knows it got four thousand views, you have data and no learning.

The fix is that the reporting export carries the same tags as the calendar, pulled from it rather than typed again. Tags entered twice diverge within a month.

Why another platform rarely fixes it

An all-in-one suite closes the seams it owns and opens new ones at its edges: your asset library, your finance approvals, your production partner, your client’s legal team.

Consolidation is often the right call. Consolidation as the whole answer is not, because the handoffs that hurt most are usually the ones crossing an organisational boundary, and no vendor sells you another company’s process.

Before a team changes tools, it is worth mapping what actually moves between them. That mapping is where most of our workflow and ops consulting work starts, and it frequently ends with the same tools and a different set of rules.

Decide the source of truth for three things

Not one system. Three decisions:

• The calendar. Where does “what is going out and when” live? One place, and it should not be a scheduler queue.
• The assets. Where does the final, approved, correctly cropped file live? One library, one naming rule.
• The sign-off. Where is a decision recorded with a name, a version and a time against it?

Everything else reads from those three. A scheduler is a publishing mechanism, not a plan. A chat tool is a conversation, not a record. A spreadsheet can be a source of truth, as long as you say so out loud and everyone believes you.

Here is the test. For each of the three, if two people on the team could give a different answer to “where is it”, you have not picked a source of truth yet.

Map your seams before you change any tool

Do this on paper, in an hour, with the people who actually do the work.

1. List every artefact a post passes through: brief, asset, caption, approval, schedule, report.
2. For each pair in that chain, name the tool at both ends and how the thing gets from one to the other.
3. Mark every handoff where a human re-types, re-uploads, re-crops or re-pastes something.
4. For each marked handoff, note the last time it went wrong and what that cost.
5. Fix the two most expensive, then ask whether a tool change is still needed.

Teams usually find more manual handoffs than they expected. You will not remove all of them, and you should not try. Removing the two worst is often the whole difference between a week that ships and a week that slips.

What good looks like

The tool set can be completely unremarkable. What matters is that a person joining on Monday can answer three questions without asking anyone.

Where do I find what is going out this week. Where do I find the approved file. Where do I see that it was signed off, by whom, and against which version.

A scheduler chosen because it does not slow the team down, a shared library with one naming rule, and an approval step that produces a yes or a no will beat an expensive suite that three people use differently.

The give-away for a system that works is boring. Nobody is asking in chat which version is current.

How NBK thinks about tool sprawl

We come at this from an operations background rather than a software one. Across the team that means UNILAD, LADbible Group, SPORF, Social Chain and Supercar Blondie, at a scale of 46,000 posts shipped and 600 million views a month, and none of it ran on a single perfect platform.

It ran because the handoffs were defined. Who owns the artefact, what the next person receives, and what counts as done.

So when a team tells us their tools do not talk to each other, our first move is not a software recommendation. It is to find the four or five points where a human is the integration, and decide which of those should stop being a human’s job.

Next step

Count your manual handoffs before you renew a licence or buy another platform. The number is usually higher than the team’s estimate, and the two worst offenders are obvious the moment they are written down.

If your social process is slowing down good ideas, NBK can help rebuild the workflow behind the content.