How a Multi-Entity Engineering Firm Runs Its Entire Bid-to-Delivery Workflow on Odoo

Since 2020, a professional engineering firm has used a single Odoo system to manage proposals, project delivery, and internal operations across four related companies. Here is how it was built, and what it produced.

The Client

The client is a multi-entity professional engineering, planning, and design-build consulting group, operated as four related companies: an engineering practice, a design and construction arm, a planning practice, and a consulting corporation, sharing staff, systems, and back-office operations under one roof. Like most firms in this space, the large majority of the firm's new work originates as a competitive proposal: a public-sector Request for Proposals (RFP) issued by a municipality, school board, housing corporation, or government agency.

That business model (win the bid, then deliver the project) is common across engineering, architecture, environmental consulting, and planning firms. It is also poorly served by off-the-shelf CRM and project tools, which are typically built around either a sales pipeline or a delivery pipeline, rarely both connected end to end with cost and time tracking in between.

Before and After

The Challenge

Before consolidating onto Odoo, a firm in this position faces a recognizable set of problems that generic software does not solve well.

• Dozens of live bids running at once, each with its own submission deadline, mandatory site-visit date, and internal review checkpoint: easy to track individually, hard to track as a portfolio.
• No structured way to see what a bid actually costs to chase in staff hours and hard costs versus what it is worth if won.
• A structural mismatch between "sales pipeline" software and "engineering delivery" software: winning a bid and executing the engineering work are different workflows (design, QA/QC, supervisor review, client sign-off, invoicing), and most tools force a choice between the two or bolt together two disconnected systems.
• A multi-entity corporate structure that standard single-company software handles awkwardly, if at all.
• No formal system for the firm's own internal operations backlog: IT requests, system changes, and access issues competing for attention with client work.

The Solution

The implementation deployed Odoo as one multi-company system spanning all four related entities, with each core module reconfigured around the realities of RFP-driven engineering work rather than left in its generic default state.

CRM rebuilt as an RFP pipeline, not a sales pipeline

Custom pipeline stages take an opportunity from first notice of an RFP through research, proposal writing, estimate drafting and internal review, submission, and award. Every card carries the submission deadline, any mandatory site-visit date, and the internal review date: the three dates that actually govern a bid team's week, visible without opening the record.

Project rebuilt around the engineering delivery lifecycle

Projects move through percentage-complete stages (Not Started, Concept Design, Engineering Review, QA/QC Review, Client Final Review, Final Review and Check, Complete), plus On Hold and Cancelled buckets, so a project's stage alone tells the team exactly where it sits in the design-to-sign-off workflow. Budgeted-versus-actual hours are flagged directly on each project card, so a project running over budget is visible immediately rather than discovered at invoicing.

Timesheets and Expenses tied back to the bid or project that generated them

Time is logged against the specific proposal or delivery task, feeding directly into the budget-versus-actual view above, including a dedicated bucket for proposal-writing labor, so business-development time is tracked separately from billable delivery hours instead of disappearing into overhead. Bid-related expenses (printing, courier, bid-portal fees, association dues) are tagged to the specific proposal, producing a clear cost-per-bid picture rather than a rough guess.

Sales, Accounting, Documents, and HR closing the loop

Quotations are generated directly from the winning CRM opportunity, preserving a clean audit trail from first contact through signed contract. A single document structure holds HR records, contracts, and finance and legal files, shared correctly across all four entities instead of four separate filing systems. HR departments mirror the four legal entities, with recruiting, appraisals, and time off running through the same system.

Helpdesk repointed at internal operations

Rather than customer support, the Helpdesk module was repurposed as the firm's own internal ticket queue for system changes, access requests, and day-to-day Odoo administration, giving the internal operations backlog the same visibility and prioritization as client-facing work.

Performance Snapshot

Why This Generalizes Beyond One Firm

Any firm that wins work through competitive or public-sector proposals (civil and structural engineering, architecture, environmental consulting, land-use planning, and similar professional-services practices) has this same shape of problem: a bid pipeline that does not behave like a sales pipeline, delivery work that needs percentage-complete visibility rather than a flat task list, and costs that need to trace back to the specific bid or project that created them.

This implementation shows this is solvable inside standard Odoo (CRM, Project, Timesheets, Expenses, Accounting, and Documents) through configuration: custom pipeline stages, cost tagging, and modules cross-linked to mirror the real workflow. No custom development was required, which keeps both implementation cost and ongoing maintenance low. The same architecture extends cleanly to any multi-entity or multi-brand professional-services group facing the same bid-driven business model.

Frequently Asked Questions

Case study prepared as a reference for Odoo implementation engagements with engineering and RFP-driven professional-services firms.