gPulse: automating the report chain of an employee-listening platform

Context

gPulse is Greenworking's employee-listening platform: a survey product that measures the social climate inside large organizations, from engagement and workload to the quality of managerial relationships. Companies run annual barometers, recurring pulses and flash surveys on it, and HR teams read the results as indicators they can act on.

The platform launched in 2016 and had CAC40 clients long before I arrived. I joined Greenworking as a full-stack developer from 2023 to 2024 and worked on gPulse. I did not create it, and this case study only covers what I worked on: the chain that turns collected survey data into the reports clients receive, and the dashboards used to explore it.

Problem

The deliverable of an employee-listening engagement is a report. Survey data comes in, analysts interpret it, and the findings are presented back to the client as slides. Assembling those slides was largely manual work, repeated for every engagement.

That is slow, it does not scale with the number of clients, and it puts consultants and analysts on formatting instead of interpretation, which is the part clients are actually paying for.

My role

Full-stack developer, working directly with the consultants and analysts who produce the reports. I automated the report production chain, from data collection through to the final presentation, and built React data-visualization dashboards used to explore the same data on screen.

[TODO: add the parts of the platform you also touched, if you want them public.]

Technical approach

Treat the deck as a rendering target

The insight that shaped the work: a report is not a document, it is a rendering of a dataset. Once you model it that way, the pipeline is the familiar one, collect, normalise, derive, render, and the deck becomes an output format rather than something people assemble by hand.

Generated output has to be right unattended

A dashboard has a user in front of it who can scroll, filter or refresh. A generated deck has nobody. It has to be correct the first time, with real client data, including the long labels, the uneven segment sizes and the missing answers that never appear in a demo. Most of the engineering effort went into the cases that are invisible when the data is well-behaved.

Survey data has its own rules

Employee-listening data is not ordinary analytics. Responses are anonymous, results are broken down by socio-demographic segments, and what a chart is allowed to show depends on how many people are behind it. Those rules live in the data layer, not in the presentation, which is another reason the report had to be generated from a processed dataset rather than assembled by hand each time.

Build with the people who use it

Working directly with consultants and analysts changed the product more than any technical decision. They knew which slides mattered, which numbers got challenged in client meetings, and which manual steps they were not ready to hand over yet. Shipping in stages, rather than replacing the whole chain at once, is what got it adopted.

Challenges

The hard constraint in this kind of reporting is that the output is client-facing at a consulting firm's price point, and it carries findings about people. A dashboard bug is an annoyance; a wrong number in a report handed to an HR director is a credibility problem. That pushes the work toward being conservative and explicit about where every figure comes from, rather than clever.

Result

The report production chain moved from manual assembly to an automated pipeline, and consultants had dashboards to explore the survey data directly.

[ADD RESULT: time saved per report, or number of reports produced, once you can share and verify it.]