Two engagements,
and what they left behind

An engagement is judged less by its deliverable than by what is left of it six months later. A register the teams still keep up to date, an instance that does not need me every week, or, in one case, a product vertical born in the field.

Organisations I have worked for

Two of them are covered in detail below. For the others, I would rather talk about them in person than write an approximate account.

The diagnosis that gave rise to a product

Diagnosis of Réunion's street lighting network, with SIDELEC as the contracting authority. The tender was won as part of a consortium; my part was the geographic data component.

In practice: recovery of the existing inventories, structuring of a light-point register that several contractors could work with at the same time, integration of the field surveys, and production of the diagnosis's map deliverables.

The segmentation was the real work. A column and its lantern: one piece of equipment or two? A cabinet feeding thirty points: what gets attached to what? These calls are not theoretical — they determine what can be counted, and therefore what can be defended in front of a funder.

What remains. A diagnosis is there to decide on a works programme, so the register has to live on after the report is handed in. That is exactly where most GIS deliverables die, and it is from that observation that the street lighting vertical of GeoLeaf Suite was born. The engagement came before the product, not the other way round.

GIS and mapping services → Equipment asset management →

Case 02

Sector: Industrial modular buildings
Tool: Odoo
Scope: Twelve users
Trigger: A signed quote
Sets off: Eight apps
Custom code: Not one line

From signed quote to job margin

A manufacturer of industrial modular buildings, and an Odoo instance implemented, then administered, for twelve users. The starting question was not ‘which apps to install’ but ‘what triggers what’. The answer comes down to a single event: a signed quote sets off eight apps on its own, including the whole supply chain.

CRM
Repurposed from its usual role. It does not track prospects, who are already qualified upstream, but the quotes to be produced, across four stages: to do, awaiting reply, negotiation, signed.
Sales
Each opportunity carries its quote, linked to the job from start to finish. Signing it is what triggers everything that follows.
Project
The signed quote creates the project that will carry the job throughout its life.
Purchase
Items procured to order generate their purchase requests to suppliers.
Manufacturing
Products sold with a bill of materials generate their manufacturing orders.
Inventory
Stock levels, receipt of the ordered materials, then delivery of the purchased and manufactured products.
Accounting
Delivery triggers customer invoicing.
Field Service
Warranty interventions and after-sales work are linked to the delivered job.
Back to the project
The loop closes: every analytic entry flows back to the project. The job's income and expenses on a single dashboard.

Running the job from the project

The project does not start out empty. On the order, a service product — let's call it ‘Job reference’ — points to a project template and its task list. Once the order is confirmed, the project is created with its named tasks, in order: thirty-one on the most recent site, without anyone entering a single line.

Since Odoo 18, the bar at the top of the project form brings the whole job together: tasks, timesheets, documents, sales orders and customer invoices, purchase orders and vendor bills, manufacturing orders, dashboard. It is configured project by project. You set the dates on the tasks, send out the requests for quotation, follow material receipts and manufacturing orders through to delivery on site — without leaving the screen.

The dashboard closes the loop: progress, hours spent, milestones, and dated project updates, each with its status, which replace the Friday email.

The detail that matters

Each milestone is linked to a task by an automation rule that works both ways: task closed, milestone ticked; milestone ticked, task closed. One precaution if you set it up: only write when the value changes. Without that, the two automations keep setting each other off.

If the job is invoiced by milestone, invoicing follows progress on site with no re-keying. If not, you still have progress tracking that is no longer self-reported.

What remains. From CRM to job margin, a single chain — and not one line of custom development: it all fits within standard configuration and a few automation rules. That is what makes it sustainable over time, Odoo version after Odoo version. On a construction job, it starts to look like site management.

Odoo services → Designing the chain before configuring it →

Demos

Seeing it work rather than
reading a brochure

Two test instances are always running. They do not show hand-picked screenshots: you can explore them, and create an intervention in them.

Generic demo

sample asset base

A mapped inventory, the full cycle of an intervention — from qualifying the request to the survey — and public reporting. Enough to judge the usability and the real pace of work, rather than a list of features.

Street lighting demo

industry vertical

Light points and cabinets, inspection rounds, and the journey of a broken street lamp, reported by a resident, through to its return to service. This is the vertical born of the diagnosis above.

Both run on a test instance, with named access. Ask for your login details: I send them with a slot for a call, to walk through the demos together if you wish.

Does your case look like one of these two?

A few lines about your context are enough to start. I reply within 48 hours, in English or French, and tell you whether I am the right fit for your project.

Describe what you need →