Starting point
The company, around 120 employees, services at two sites, was typical for its size: no IT team of its own, an external provider for laptops and accounts, and a cloud tool for everything else. Personio for personnel data, Slack for communication, Google Calendar for appointments, a task list for projects. None of them talked to the others, and the connection between them was called HR: two people who created every new hire in Personio and then retyped it into Slack, calendar and task list.
The moment it tipped was a new hire in summer. The Slack welcome went out on Monday, the calendar appointment for the first conversation was created on Wednesday, and the manager found out on Thursday that her new colleague had been in the building for three days. Nobody had forgotten anything, each step had simply happened on a different day. The same week it turned out that a probation period had expired two weeks earlier without anyone holding a review. The deadline sat in Personio, and the manager had never looked there. The head of HR called me the following week.
At the first meeting the head of HR, her colleague and the works council chair sat at the table; there was no IT to invite. The works council chair said he had not co-determined Personio and Slack back then and did not want to miss that again with a tool that connects the two. The head of HR said she did not want another system someone has to maintain, but one that connects the existing ones. Both together were the foundation: a cloud service that HR runs itself, and a works council that builds along from week one.
Approach
Week one belonged to the stopwatch, as always. Both people in the team noted which task came how often, into how many systems it was typed and where a decision sat behind it. Three processes ended up at the top: the new hire with its four systems, the probation period that lived only in Personio, and the onboarding survey that went out when someone remembered. None of the three needed a decision in the first step; all three consisted of retyping, reminding and asking back.
In week two I created the organisation in Make together with the head of HR, in the company's account, not in mine. When you create it, Make asks whether the organisation should sit in the EU or the US region, and according to the documentation that cannot be changed afterwards. We chose EU; that was the first item on the external data protection officer's list. The same day the works council chair sat in the room, and the first scenario was drawn not on screen but on paper: what triggers it, which fields it needs, who receives which message, where a human decides. Five fields flow out of Personio: first name, team, start date, location, manager. Salary, date of birth and address stay where they are. Only when HR and the works council had signed off the sketch was it rebuilt in Make.
The finished scenario is simple, and that is deliberate. The trigger is a new record in Personio with the status onboarding. Make reads the five fields, drafts the welcome for the team's channel, creates three appointments in the manager's calendar and generates the task list from the template, assigned to the manager and the provider. None of it goes out before HR has seen it: the scenario sends a summary to HR, and only after approval are appointments confirmed and the welcome posted. The works council chair had insisted on that step. Finally Make writes the date back into a field in Personio so the same hire is not processed twice.
The snag came at the first test. The welcome that was meant for the manager landed in the channel of the entire company, because the filter for the team channel was not in place yet and Make had taken the channel from the template. It was a test record with an invented name, so no harm done, but since then every scenario runs without Slack connected until all filters are checked. The probation reminder was built quickly after that: Make checks the probation end date in Personio daily, filters for six weeks before, and sends the manager a message with the link to the company's conversation guide, copy to HR, no assessment, only the date and the guide. The onboarding survey goes out on day 30 as a form without a name field, the answers land in a table without a sender, HR reads the total once a quarter.
The works agreement ran in parallel. A service that moves personnel data between systems and monitors deadlines is subject to co-determination; that was a given from the start. The text grew out of the signed-off sketches: which three scenarios run, which five fields they read, that HR approves before anything is sent, that the survey knows no individual evaluation, how long Make keeps the execution logs, and that every new scenario is shown to the works council first. The external data protection officer reviewed the data processing agreement that Make provides in its contractual documentation, including the list of subprocessors, and the chosen EU region. After three months the agreement was signed, the three scenarios ran in production, and the team maintained them without me.
Outcome
A new hire now starts with the record in Personio and ends with an approval by HR; there is no more typing. The manager has her three appointments in the calendar on the day of approval, the welcome appears in the right channel on day one, the task list sits with the provider. Six weeks before every probation end the manager has a message with the guide, and HR sees the copy. The survey goes out on day 30 without anyone having to remember.
Personnel data flows through Make, that was clear from the start, and that is why the organisation sits in the EU region, the data processing agreement is reviewed, and exactly five fields flow. The works agreement names the three scenarios, the fields, the approval step, the retention of logs and the procedure for new scenarios. At the six-month review the team presented a fourth scenario, the reminder for the exit interview, and built it themselves, on paper first, with the works council. That it needed neither an IT department nor me was the goal.