How We Turned a Spreadsheet Nightmare Into a Publishing Engine

Stack: ASP.NET Core · SQL Server · Vue.js · Hangfire · Azure Service Bus · OpenXML

Every agency eventually hits the same wall.

The content team is producing good work. The clients are (mostly) happy. The process is technically working. And then someone asks: "Can we take on twenty more clients?" And you look at the spreadsheets, the shared folders, the email threads, the manual copy-pastes - and you realise the answer is no. Not because of talent. Because of infrastructure.

That was the situation at MSP Marketing Edge. A growing managed services marketing agency producing weekly social content for a portfolio of technology clients across the UK and US. Their editorial team was capable. Their clients were engaged. Their process was manual and reliant on a lot of human effort.

The Problem Wasn't Content. It Was Coordination.

When we sat down with the team, the instinct was to talk about features. What the platform should do. We pushed back on that immediately, because features are answers, and they hadn't finished asking the questions yet.

What they actually had was three compounding problems:

One editorial team. Hundred of clients. No shared source of truth. Content was being created centrally, and distributed to each client. Every week. By hand. The error rate was low, because the people doing it were skilled, but the time cost was enormous and the ceiling was obvious.

Clients needed control. Not chaos. Clients wanted to tweak copy, approve posts, and connect their own scheduling tools. But giving them unstructured access to production content was a support nightmare waiting to happen. They needed controlled customisation, not a free-for-all.

Automation was optional, not impossible. Several clients wanted a "set it and forget it" publishing pipeline. Others wanted weekly sign-off. The platform needed to serve both without treating one as the default.

Once we'd mapped those three problems clearly, the solution architecture wrote itself.

What we built

MSP SocialTools is a role-based content operations platform. Not a social media scheduler. Not a CMS. An operations platform, built around the reality of how a content-at-scale agency actually runs its week.

The editorial engine

Editors work in a structured weekly dashboard. Seven day slots, Monday to Sunday, with long-form and short-form copy fields per day — because LinkedIn copy and Twitter copy are not the same thing, and platforms that pretend they are produce worse output for both. UK and US locale variants are handled natively, with one-click cloning from the base language when regional differences are minor.

When a week is ready, a single publish action distributes the canonical content into every eligible client account simultaneously. What took an editor an afternoon now takes seconds.

The client layer

Clients receive their weekly posts in a private dashboard. They can edit, reorder, and lock individual posts. Locking is the approval signal. Locked posts flow downstream into the RSS scheduling logic. Unlocked posts stay as drafts. It's a simple mechanism that does a lot of work: it separates "I'm still thinking about this" from "ship it."

Clients who want to run on autopilot can enable automated publishing mode, which locks and schedules posts without weekly intervention. Clients who want oversight stay hands-on. The platform doesn't decide for them.

The blog automation pipeline

One recurring pain point was blog promotion. Every week, someone needed to manually pull the latest blog URL, write a short excerpt, drop it into the right day slot, and push it live. It was small work. It was also the kind of small work that gets forgotten under pressure.

We replaced it entirely. External blog platforms push a payload to the API. Azure Service Bus queues the message. A background job processes it and seeds the right client's weekly schedule automatically. If automated publishing is enabled, it goes straight to RSS. No human in the loop unless the client wants one.

Scheduler-ready outputs

Not every client uses the same scheduling tool. Buffer, HubSpot, Hootsuite, Publer - each has its own import format. Rather than telling clients to adapt, we generate platform-specific export packs: ZIP bundles containing pre-formatted CSVs per scheduler, shaped to each tool's exact schema. The client picks their platform in settings. The export takes care of the rest.

The Architecture Underneath

The platform runs on ASP.NET Core with Razor Pages, Vue components for the interactive dashboards, and SQL Server as the primary store. Hangfire handles recurring background jobs, such as RSS publishing, queue processing, and housekeeping. Azure Service Bus decouples the blog ingestion pipeline from the processing layer, so high-volume blog pushes don't block anything.

The data model makes a distinction that matters: SocialPost (the canonical editorial content) and CustomSocialPost (the client-owned instance with its own state). This separation is what makes centralised publishing with per-client customisation possible. Without it, you end up with either a locked-down broadcast system or a forked mess of client-specific content that can never be updated in bulk.

It's the kind of architectural decision that doesn't look impressive in a demo. It's the kind that saves you a world of pain eighteen months later.

What It Delivered

The gap between "working" and "scalable" turned out to be about a week's worth of content chaos. After deployment:

• Editorial throughput increased significantly - weekly publishing that previously required manual per-client distribution was reduced to a single action
• Client onboarding was accelerated - new accounts are seeded with recent published content automatically; no empty-week cold start
• Blog promotion became systematic - zero manual steps required for clients using the automated pipeline
• Export compatibility was resolved - platform-specific CSV generation eliminated recurring reformatting overhead

The operational ceiling the team had hit wasn't a people problem. It was a tooling problem. The platform removed it.

The Takeaway

The best internal tools don't feel like software. They feel like the way the work was always supposed to be done.

MSP SocialTools isn't glamorous. There's no AI-generated copy, no viral dashboard, no blockchain. It's a publishing operations platform that solves a genuine workflow problem for the people who have to live inside it every week. That's the brief we were given, and it's the brief we built to.

If your agency is scaling and your process is still held together by spreadsheets and goodwill, that's not a content problem. That's a systems problem. And systems problems have solutions.