HiBob prototypes customer features inside ChatGPT before shipping them via API

The 2,500-to-200 funnel is the real number

The headline figure OpenAI leads with is that 90%+ of HiBob employees actively use ChatGPT Enterprise. The more instructive number is buried underneath: 2,500+ experimental GPTs built, of which 200 were successfully deployed into internal workflows.

That is roughly a 1-in-12 survival rate. HiBob frames this positively, and it should — the funnel implies that most GPTs are cheap to create and cheap to abandon. The custom-GPT builder is being used as a disposable prototyping surface, not a production runtime.

For anyone shipping AI features, that ratio is the interesting part. It means the interface people build in is not the interface most builds are meant to survive in. The GPT is a probe.

Where the frontend actually lives at each stage

HiBob's cycle has two distinct frontends. Internally, employees interact through the ChatGPT Enterprise GPT interface — the Meeting Prep GPT that pulls CRM data and transcripts, the Upsell GPT reading usage patterns, the SEO Assistant hitting web analytics APIs. These are conversational surfaces sitting on top of internal systems.

Externally, the source says HiBob takes solutions it built and tested in ChatGPT Enterprise, then implements them with OpenAI's API to deliver features inside the Bob platform. The customer-facing conversational experience — HR leaders querying their data and getting decisions in minutes — runs on GPT-4o through the API, not through a shared GPT.

So the same idea gets rendered twice: once as an internal GPT to validate whether the interaction is useful, and again as a first-party product surface once it proves out. The conversational pattern is portable even when the hosting layer is not.

The five-step process treats a chat interface like a shipped product

HiBob's AI Mind team put structure around the prototyping mess: idea and proof of concept, build, adoption and enablement, maintenance, and scale. Notably, the adoption step requires documentation, training, and a named owner for each GPT. The maintenance step adds feedback loops.

This is the discipline that separates a demo from a durable interface. A GPT with an owner and a maintenance loop can absorb the churn that kills most internal AI tools — model updates, drifting prompts, changing source systems. The 200 that survived are the ones that got this treatment.

"We're focused on allowing people to do more with more. Each agent has a role, just like each employee does. That's what makes the system sustainable." —Ori Simantov, AI Adoption and Insight Lead, HiBobMontana Labs

The searchable internal directory for reuse is the frontend detail that scales this. Once an agent works, its interface pattern becomes a template others adapt rather than rebuild.

What the adoption-to-product loop implies for feature teams

The specific lesson here is that HiBob collapsed the gap between internal tooling and product roadmap. Employees using an internal GPT are, in effect, running usability tests on a feature the company may later sell. The people who feel the pain design the fix, and the successful fixes become customer features.

For frontend and product teams, this suggests treating the GPT builder less as a novelty and more as a fast, low-cost staging environment for conversational interactions — with the explicit expectation that most will be discarded and the survivors will be rebuilt on the API for the real product surface.

The risk HiBob does not address is fidelity: an interaction that works inside ChatGPT Enterprise's polished chat frame may behave differently when re-implemented in Bob's own UI on GPT-4o. The prototype validates the idea, not the production experience. That gap is where the second engineering pass earns its keep.