Manual routine, replaced by systems that run themselves.

The problem

One to three hours per commercial proposal, with the predictable consequences: slow responses to hot leads, inconsistent documents, arithmetic errors, and prices that were already out of date by the time the PDF was sent.

How it works

• A 9-step wizard with four calculation modes — the manager answers questions instead of doing math.
• A calculation engine in custom JavaScript: 24 regions mapped onto 5 solar insolation zones, each with a real 12-month generation profile, so the yield forecast is location-accurate rather than a flat annual average.
• Automatic equipment selection — inverters, panels and storage units picked from a catalog to match required power, with quantities and totals derived automatically, plus credit logic with differentiated payment schedules and dual-currency handling.
• A document pipeline: Google Docs template copied and filled via batchUpdate, conditional page removal, generated charts and the client's own logo injected, then PDF post-processing through a self-hosted Stirling instance — compression, page removal, split and merge.
• Two product lines from one system: solar power plants and battery energy storage, each with its own template set and its own rendering branch.
• An admin layer with no code — six extra webhook endpoints let non-technical staff manage the catalog, price list, managers and settings from a UI. Price changes no longer need a developer.

Result

The problem

The call center and sales department were a black box. Nobody could say how managers actually talked to customers, where leads were being lost, or whether the script was followed. Out of hundreds of calls, a few were ever reviewed.

How it works

• Transcription with speaker diarization — the telephony platform fires a webhook the moment a recording is ready; AssemblyAI transcribes it, with a polling loop and retry logic while the transcript is being prepared.
• Department routing — call center, sales, credit and service are each scored against their own rubric.
• Five specialized LLM agents work in parallel, each owning one block of the scorecard and each returning strict JSON through a structured output parser: greeting and contact establishment, needs discovery, solution presentation and objection handling, next-step agreement, and a final agent that writes the CRM note in HTML.
• A fair rubric, not just an automated one — agents award full marks when the client is not a decision-maker or redirects immediately, so managers are never penalized for conversations they could not control. The interest score from the first agent gates the ones downstream.
• Failure handling that matters — a dedicated error branch with a retry counter and wait steps, so no call is ever silently dropped by a transcription API hiccup.
• Two dashboards fed from the logged results, with a per-employee breakdown leadership uses for coaching.

Result

The problem

Unknown numbers never became leads. Missed calls left no trace. No report on call activity could be trusted, because the data underneath it was incomplete by construction.

What happens on every call

• A webhook fires on call completion; the number is normalized and checked against an exclusion list held in Supabase with a Google Sheets fallback — internal lines, partners and service numbers never pollute the CRM.
• The operator's telephony extension resolves to their CRM user through a mapping table, so the activity lands on the right owner.
• The contact is looked up in Pipedrive and created automatically if missing — an unknown number becomes a lead with nobody typing anything.
• Open deals for that contact are searched, so the call attaches to the right deal instead of floating loose on the contact record.
• A routing tree across call type × department selects the correct one of roughly 15 activity templates — answered, no-answer or service, with or without an existing contact — then patches on call duration and the recording link.

Result

The flow

A manager moves a deal to the project stage in Odoo. A webhook reaches n8n, which creates a Telegram group through a Telethon-based service, adds the right participants by username, posts a structured project brief as the first message, links the group to an Odoo Discuss channel with two-way sync, and generates the task checklist across all eight delivery stages — survey, financial calculation, proposal, contract, payment, delivery, installation, commissioning.

The bot is also the admin tool

• Group and user operations — create a group, add, find or remove a user, each with a live "processing" message edited in place with the result.
• Group listing with filtering and paginated inline-keyboard navigation.
• An ignore list and group registry maintained in Google Sheets by the people who actually use them.
• Full action history and on-demand reports — the workflow checks whether the target sheet tab exists, creates it with headers if not, then appends. Reporting never breaks on a missing tab.

Result

What the module suite does

• Four access roles with distinct permissions and views: call-center operator, sales manager, credit specialist, director.
• Three lead queue types, so each role pulls from the right pool instead of browsing a shared list.
• Manager pause — a controlled way for a rep to stop receiving new leads without being removed from distribution.
• An inter-department transfer wizard with full logging — every handoff between call center, sales and credit records who, when and why. The funnel became auditable instead of anecdotal.
• 15+ KPI metrics per manager, computed in the system and available to leadership without exporting anything.
• Integration surface: automatic project initiation on deal progression, two-way Odoo Discuss ↔ Telegram sync, call-recording hooks feeding the AI analysis, and a ~90% Pipedrive → Odoo data migration.

Result

The work

• Process discovery across departments, documenting the real as-is workflows — including where data was duplicated and where handoffs broke.
• 10+ platforms evaluated — Pipedrive, Bitrix24, HubSpot, Monday, Asana, Jira, Notion and others — against weighted criteria: customization depth, total cost of ownership at scale, data ownership, API quality, and the ability to absorb a non-standard delivery process.
• Self-hosted Odoo Community recommended, on the grounds that unlimited customization through Python modules was the only way to model the real process without paying per user for features the company would never use.
• A delivery model designed around the budget: an in-house BA/PM owning requirements and quality, with external integrators executing — cheaper than a full in-house team, safer than handing the system to an agency.
• Migration executed via the Pipedrive API and Odoo RPC.

Result