Case Study: Hundreds of job ads, half the time-to-publish — the secret sits in the code

Imagine you're a large corporate group with several brands, distributed sites and different HR departments. For applications you don't use one system, but several. Grown over time, every brand has its own preference. And then there's the careers site, which is supposed to show every vacancy. In real time. Attractively. Searchable.

That's exactly the scenario we found at one of our customers. Hundreds of open positions in parallel, several applicant tracking systems in the background, a high editorial maintenance load, and a time-to-publish per ad that nobody was happy with. After working together, the average time-to-publish per job ad has been halved. The secret isn't in a bigger budget. It sits in the code and in a properly automated process.

Starting point

The customer runs several brands under one corporate roof. Individual companies use different applicant tracking systems for applications and recruiting — partly for licensing reasons, partly for historical preferences of the respective HR teams. The group-wide careers site ran on TYPO3 and was supposed to show all vacancies from all systems consolidated: filterable, searchable, geo-sorted, with a unified look and feel.

Before our project, day-to-day looked like this: vacancies were entered in the respective systems. Then they were transferred to the careers site, partly manually, partly semi-automatically. There they were edited editorially, given brand imagery and sorted into matching categories. Changes in the source systems often only landed on the careers site days later. Expired ads stayed visible too long. The time-to-publish per vacancy was unnecessarily high, because the path from “publish now” to the first application took longer than it had to.

What we built

A central integration layer

Instead of maintaining a separate export path for every applicant tracking system, we built a central integration layer. It speaks to the various HR system APIs, normalises data into a unified model — job title, location, entry level, business area, contact person, application link — and stores it in a consolidated structure that the TYPO3 system can access.

The decisive point: this layer isn't a new third-party system somebody has to log into. It's part of the platform, documented to a standard, and part of our operations. The HR teams keep working in the systems they know. The bridge to the careers site is invisible.

Automated publication with rules

On top of the consolidated data model we implemented defined rules that determine which vacancies become visible when and where. That includes matching with brand assignments, taking expiry dates into account, and the automatic mapping to categories and locations. Vacancies appear as soon as they're released and disappear on schedule — without anyone having to remember.

Multi-site publication

The careers site isn't the only place where the vacancies are shown. Brand-specific landing pages, location micro-sites and external job portals are served in the same pass. From one data source you get output for many channels — a classic multi-site scenario we've cleanly mapped as CMS as a Service.

Automated monitoring

Because every hour matters in recruiting, we set up monitoring for the entire data flow. If an API of a source system goes down, our operations team gets a notification before HR or the editorial team notice. If an ad doesn't behave as expected, it's surfaced.

Result

The measurable effects after rollout:

Time-to-publish per job ad halved. From entering in the source system to visibility on the careers site and relevant portals, minutes pass today, not days.

Significantly less editorial work. The central team no longer maintains content it never created. Corrections and enrichments happen where the data originates.

Higher data quality. Expired vacancies are reliably removed from visibility. Duplicates across channels have disappeared.

More applications on the same budget. Faster visibility and consistent presentation on brand and location pages have measurably triggered more qualified applications.

What was decisive from our point of view

Two things we want to emphasise, because they're underestimated in many similar projects. First: we didn't replace existing systems. We connected them. Every HR system stays where it is. No new licence, no new training, no political debate about market power. Second: the automation isn't built as a one-off project, but as part of our platform operations. Maintenance, monitoring and ongoing development run in the same processes as the rest of your CMS.

Who this is relevant for

We don't only see this pattern in recruiting. Wherever you need a consolidated presentation today from several source systems — product catalogues, location data, events, publications — the same principle applies. Standardised integration layer, clear rules, automated publication, multi-site output.