About E-deal and its documentation
E-deal is the CRM platform of the Efficy Group, built and hosted in France since 1998 and used by more than 90,000 people across several hundred client organizations — heavily represented in banking, insurance and mutual insurance, social housing, and the public sector. Customers can go beyond configuring settings: integrators can extend the underlying code itself, which means a given deployment can end up looking quite different from the base product. Emmanuel Vaillant is Product Lead for E-deal.
Documentation ownership shifted to product managers
Efficy used to share a dedicated documentation team across the group's different products, responsible for keeping every product's docs aligned in style and branding. That stopped working as each product line became more independent — different products now use different documentation tools entirely, and there was no longer a shared standard to justify a centralized team. Today, documentation ownership sits with product managers: whoever owns a feature is responsible for making sure it's documented when it ships.
For each topic we are building with the engineering team — at the end of the topic, so the new feature or new implementation — the product manager has to update the documentation.— Emmanuel Vaillant, Product Lead, E-deal
Publishing a single article change could eat half a working day
Before ClickHelp, E-deal's documentation lived in Help&Manual, originally seeded years earlier by importing one large Word file that nobody had properly cleaned up since. The result was years of accumulated formatting debt — legacy inline styles, leftover Wingdings bullet characters, broken alt text — and a publishing process complex enough that updating one article could take most of a day.
Just to update one article, I could pass one midday just for that.— Emmanuel Vaillant, Product Lead, E-deal
Six months of manual cleanup work compressed into days, using ClickHelp's MCP Server
Before
After
ClickHelp's MCP Server gave Emmanuel a way to restructure and clean the entire E-deal CRM documentation set from scratch, using Claude to do the reading and rewriting at scale.
| Before | After | |
|---|---|---|
| Articles in scope (French content) | 2,915 | 1,793 |
| Change | — | −1,122 articles (−38%) |
| Estimated effort, manual | ~6 months, full-time | — |
| Actual time taken | — | A matter of days |
The work went beyond deleting duplicates: hundreds of articles were rewritten into clean HTML — stripping legacy style and script blocks, Wingdings bullets, inline styles, and broken alt text — and the table of contents was restructured across every major module, with articles merged, redundant hierarchy levels removed, and orphaned articles relocated to where they belonged.
This work would conservatively have required a full-time person for six months. It was done in a matter of days.— Emmanuel Vaillant, Product Lead, E-deal
To do it, Emmanuel used ClickHelp's MCP tools for both structure and content: reading and auditing the table of contents, reorganizing it, and reading and rewriting article bodies at scale. Moving articles around without being able to touch their content, or rewriting content without a way to reorganize where it lived, would have solved only half the problem.
The combination of structural tools and content tools covers exactly what you need to drive a documentation project programmatically.— Emmanuel Vaillant, Product Lead, E-deal
Every tool behaved exactly as documented, responses were consistent, and I never experienced unexpected errors or data loss throughout the entire project.— Emmanuel Vaillant, Product Lead, E-deal
A shared Claude project defines the title format, tone, and structure every article follows
One side effect of cleaning up years of accumulated content: Emmanuel noticed just how inconsistent the writing had become — some articles precise and technical, others reading more like marketing copy, depending on who wrote them and when. He built a Claude project with explicit rules for article titles, tone, and structure, and used that same project for every new article going forward. He tested it deliberately: he and another product manager independently prompted Claude to document the same feature using the shared project, and the results came back close enough to be functionally the same article.
He also chose a shared project over individual Claude skills deliberately — skills only fire if you remember to invoke them correctly, while a project's instructions apply automatically to everyone using it, which made adoption across a small team far more reliable.
All articles are written in the same way, not depending on if it's me or an engineer or a marketing person.— Emmanuel Vaillant, Product Lead, E-deal
Combining ClickHelp's MCP server with the Atlassian Jira MCP to go from a finished epic to a published article
For new features, the workflow starts once an epic and its tickets are marked done in Jira. Emmanuel prompts Claude with the epic details; Claude, already primed by the project's rules on tone and audience, drafts the article. After a round of revisions, Claude checks whether an existing article should be updated instead of creating a new one — and, critically, waits for explicit sign-off before writing anything back to ClickHelp. Only once Emmanuel confirms does Claude call ClickHelp's create_topic or update_topic to publish the change.
Running this workflow at scale surfaced a few practical lessons worth passing on:
- Use Markdown rather than HTML for audit reads. It uses fewer tokens while preserving enough structure and content to evaluate an article effectively.
- Batch reads before making changes. Reviewing several related articles together makes it easier to spot duplication, inconsistencies, and consolidation opportunities before anything is rewritten.
- Work in smaller, focused batches. Processing related sections separately keeps the context manageable and makes the resulting changes easier to review.
What Efficy learned from the project
Start with a real cleanup problem, not a demo. E-deal used MCP because its documentation had years of accumulated structure and formatting debt, and the work needed both content edits and changes to the table of contents.
Keep a human approval step before publishing. Claude could prepare or update an article, but Emmanuel reviewed the change before anything was written back to ClickHelp.
Plan for the gaps in the toolset. During the cleanup, E-deal could hide obsolete articles in bulk, but deleting them still required a manual step in ClickHelp.
Before AI, nobody documented anything, because it took too much time. Now everybody documents everything — even things that don't need documenting. I get a lot more documentation, but not necessarily more useful documentation.— Emmanuel Vaillant, Product Lead, E-deal
