Each manufacturer has its own Tracings cycle. Philips in particular has a date that moves. Today these dates live in Kari's head, in a spreadsheet, and in occasional emails. Missing one is a compliance event.
A single compliance calendar that lists every manufacturer's Tracings cycle, including the variable Philips date, with reminders at T-10, T-3 and T-0. Kari and Shahin both see the same calendar; nothing falls into a personal inbox.
No missed deadlines. Less personal cognitive load on Kari. The team can plan workload around known peaks instead of discovering them mid-week.
The full list of manufacturer Tracings cycles and how the variable Philips date is set each month. Low lift — mostly Kari's knowledge written down once.
At the start of every month Kari pulls the AEDTS licences report, identifies the cohort of customers due to renew, and creates the corresponding Odoo deals one by one — including the supply-tier and pricing decisions. This is the single largest recurring task in Account Management.
An automated batch run: read the AEDTS expiry list, match each customer to the existing Odoo account, infer the tier from supply inclusion in the previous cycle, and pre-create the renewal deal at the right amount. Kari reviews the batch in one screen, edits the exceptions, and sends. What is a one-and-a-half-day exercise today becomes a one-hour review.
Roughly one to two days per month back to Kari. The renewal cohort is never missed, even when she is on leave. The process becomes independent of any single person's memory of which customer gets which tier.
A sample AEDTS licence export, the tier and pricing rules Kari applies, and Odoo Sales access. ~1h with Kari to map the logic.
Each manufacturer (Defibtech, Stryker, Philips, Zoll, others) requires a differently-shaped Tracings spreadsheet, with lot and serial detail per end user. Today this is assembled by hand each cycle by Kari, with serial numbers pulled from QuickBooks free-text description fields. It is one of the most error-prone exercises in the operation.
Now that lots and serials are first-class records in Odoo Inventory, build a per-manufacturer template renderer. The renderer reads the structured serial data plus the end-user data, applies the manufacturer's required shape, and emits the spreadsheet ready to send. Kari validates and sends; she does not assemble.
What is a multi-day exercise becomes a review step. Errors drop because the data comes from the system of record, not from copy-paste. Audits become much easier to respond to because the underlying data is already in the right shape.
One sample spreadsheet per manufacturer (Defibtech, Stryker, Philips, Zoll), and confirmation that lot/serial data in Odoo is complete after the migration.
After a quote goes out today the follow-up cadence is fully manual. Each sales representative tracks the next nudge in their own inbox or in their head, and the cadence varies by rep and quote type (training, product, rental, AEDTS renewal). Leads that arrive in volume — especially the long tail of smaller quotes — tend to slip simply because there is no system reminding the rep to act.
Build a configurable follow-up sequence engine on top of Odoo Activities. Each quote type gets its own pre-defined cadence (for example: day +3, day +7, day +14, day +21) with draft email copy per touch. Odoo automatically schedules the next activity, drafts the email body using the deal context (account name, products, total, expected close date), and notifies the owning rep when it is ready to send. The rep retains a one-click 'send' or 'snooze' option, so the cadence is automated but the relationship stays personal.
Every quote receives a consistent follow-up rhythm, removing the silent drop-offs that today depend on individual diligence. Reps recover three to four hours per week each (estimate from the sales review with Prabhakar and Enrique), and the team is able to respond inside the two-hour first-contact SLA more reliably as lead volume grows.
The cadence and draft copy you want per quote type (training, product, rental, AEDTS renewal), plus Odoo admin access to configure Activities. ~30 min with Prabhakar and Enrique to confirm the rhythm.
Carolina described the close cycle as a manual stitching exercise across QuickBooks Online (or Desktop, until very recently), Odoo, and a set of personal spreadsheets. There is no single screen that answers the three questions that drive every Monday morning: what is due this week, what is overdue, and how much cash actually came in.
Build a single AR dashboard that pulls live data from Odoo Accounting (and QB Online during the transition period) and shows: upcoming invoices due in the next seven days, sent-but-unpaid invoices by age bucket, payments received this month, and the customers with the largest exposure. Drill-downs go straight to the invoice in the source system.
Carolina recovers two to three hours per week today spent reconciling reports across systems. Leadership sees AR health without having to ask. The month-end close shortens because the inputs are already aggregated.
Read-only API access to Odoo Accounting and QuickBooks Online, and ~30 min with Carolina to define the three views (due this week / overdue / cash received).
Reminders for unpaid invoices are sent manually. Carolina flagged that some accounts (Capistrano, certain school districts, key government customers) must explicitly not receive automatic dunning emails — relationships there are managed personally. So the team errs on the side of caution and sends nothing automatically at all, which slows collections across the entire book.
Configurable dunning sequences in Odoo Accounting, with an explicit 'do-not-auto-dun' flag per customer that the account manager can toggle. Sequences vary by customer segment (distributor, direct, government, training). Each step has a drafted email; the sequence escalates politely up to a final human-review step where Carolina or Kari is asked to call.
Days Sales Outstanding drops because the long tail of small overdue invoices finally gets a polite, on-time nudge. Key relationships are protected. Carolina spends her time on the accounts that genuinely need a human conversation.
The list of do-not-auto-dun accounts (Capistrano, school districts, key gov), the customer segments, approved reminder copy per step, and Odoo Accounting access.
End-of-month and end-of-quarter reports — sales-tax returns, the monthly close pack for leadership, the payment-status report Operations needs — are assembled by hand from QuickBooks exports. The structure of the reports changes slightly each time, and the assembly is one of the more tedious recurring tasks in Finance.
Schedule each report directly out of Odoo (or, during transition, out of QB Online) with the structure standardised and the deltas highlighted automatically. AvaTax already owns the sales-tax calculation; the report becomes an export-on-demand rather than a build-from-scratch exercise.
A day to two days of Carolina's month-end time is given back. Leadership sees the same numbers in the same place every month, with the trend baked in.
Sample copies of the current monthly reports and the structure leadership wants, plus Odoo/QuickBooks + AvaTax export access.
Subscription quantity changes today require a manual sync to Stripe. When the two records drift — quantity in Odoo does not equal quantity in Stripe, or a Stripe payment fails for more than a few days — no one notices until Kari finds it on the next renewal review.
A health monitor that compares Odoo subscription state to Stripe state on a schedule. Any drift in quantity, any payment failure older than N days, any subscription where the customer is paying for a service that was downgraded in Odoo — surfaces on a single screen. Kari is paged on the exceptions, not on the entire portfolio.
Revenue leakage from stale Stripe quantities is caught before the next renewal cycle. Failed-payment recovery starts faster, which materially lifts subscription retention.
Stripe API + Odoo Subscriptions access, and the thresholds for what counts as drift or a stale failed payment.
The native New Lead form in Odoo is long. During an inbound phone call — when speed matters most — the rep needs to capture five or six pieces of information (name, email, phone, company, lead source, a couple of notes) and finish the call without losing the prospect. Enrique flagged this in the sales review as a daily friction point that pushes some leads to be created afterwards, from memory or from notepads.
Build a short-form lead-entry modal that exposes only the minimum viable fields and writes them straight into Odoo CRM as a lead. Progressive enrichment (lead source detail, industry, account links) happens afterwards, either automatically from the email domain or by the rep when they have time. The modal can be opened from a desktop shortcut, from a browser extension, or from a chat command.
Calls end with the lead already in Odoo, not on a sticky note. Zero leads lost to forgotten follow-up entry, and the rep stays in the conversation instead of fighting the form.
Confirmation of the 5-6 must-have fields for a phone intake, and Odoo developer/admin access to add the modal. ~20 min with Enrique to lock the field set.
AEDTS holds the primary liaison email per customer; QuickBooks (and increasingly Odoo) holds the billing contact. These two sets diverge over time, and Kari catches the discrepancies one by one when invoices bounce or renewals fail to reach the right person.
A reconciliation job that compares the AEDTS primary-liaison data against the Odoo contact set, surfaces the deltas in a single review screen, and lets Kari approve, merge, or correct in one pass. Run monthly, ahead of the renewal batch.
Renewal emails reach the right person on the first try. Bounce-back rate drops. Customer contact data quality compounds over time instead of decaying.
An AEDTS primary-liaison export and Odoo Contacts read access, plus Kari's rule for which source wins on a conflict.
Today the renewal cohort is tracked on a Trello checklist or in Kari's personal spreadsheet. There is no live view that leadership can open to see how the current month is progressing.
A single dashboard pulling from Odoo deals (renewals issued, sent, paid, outstanding, auto-renewed via Stripe) for the current cohort. Filters by tier, by brand, by sales channel. Replaces the Trello checklist entirely.
Kari, Shahin and leadership all see the same renewal picture in real time. The end-of-month surprise is removed. Forecasts for renewal revenue become reliable inputs to the cash model.
Odoo Sales + Stripe read access, and confirmation of the cohort definition and filters Kari and leadership want to see.
Tracings data also comes back from distributors. Today Kari emails each distributor individually, tracks responses in her inbox, and re-pings the laggards by hand. The deadline pressure builds in the second half of each month.
Automate the outreach: generate the personalised request spreadsheet for each distributor, send it on schedule, track the response status, and auto-nudge at T-2 days before the deadline. Kari sees a single status board covering every distributor.
The deadline becomes a question of who has not yet responded, not who Kari has not yet emailed. Late submissions drop. Compliance posture improves without additional headcount.
The distributor contact list, the request template per distributor, and the monthly collection deadlines.
AED events (loaner ships out for a corporate event, returns, and any incident is documented) are tracked across a shipping delivery, ops notes and emails. Beth flagged this as the workflow most likely to drop steps under load. Three new SKUs in Odoo now trigger the ops project, but the lifecycle is not yet orchestrated end to end.
Wrap the AED-event lifecycle in a single tracked Odoo project with explicit stages: event validated → loaner sent → loaner delivered → event AED returned → incident report captured → closed. Each stage has its checklist, the reminders are automated, and the return-AED line stays pending until the device is physically back.
Zero dropped follow-ups on events. A clean compliance trail when an incident is reported. The ops team works from a queue, not from memory. Beth recovers an estimated thirty to forty-five minutes per event.
Odoo Projects access and Beth's walkthrough of the event lifecycle stages plus the checklist per stage.
Today the inspector app returns to the device list after a successful scan and check, forcing the inspector to navigate back to the AED detail to confirm the freshly-updated check history. Over a day of inspections this adds up — Taso and Oscar flagged this specifically.
Change the post-scan flow: after a successful scan and OK check, stay on the AED detail page and surface the new check entry. A single tap returns to the list when the inspector is ready.
Less friction per AED, more inspections per day, fewer moments where the inspector second-guesses whether the scan registered.
Access to the inspector-app codebase / dev cycle, and a quick confirm from Taso and Oscar on the exact post-scan flow.
Inspections happen in airports, schools, fitness centres and industrial sites where cellular and Wi-Fi coverage is unreliable. The app today expects a live connection, so inspections in dead zones stall or are reconstructed later from paper notes.
Make the app offline-capable: cache the organisation's full AED list on login, queue check submissions locally, and sync everything once the device reconnects. Conflict resolution at sync time is a small set of well-defined rules.
Inspectors finish a site in one pass, not two. No more lost data on bad-signal days. Customer confidence in the service improves because the inspector visibly works through the entire site without 'I'll re-enter this later.'
Inspector-app dev access and a decision on the sync conflict-resolution rules. Bigger build — worth scoping the effort early.
Multi-site customers — school districts, large corporates, SCE, El Segundo, Capistrano, the airport accounts — are modelled today as a flat list of customers with per-site routing handled by Beth and Carolina manually on each order. Addresses, billing contacts, and PO routing rules live in Carolina's head.
Use the Odoo Contacts parent / sub-entity model end to end. Each holding or district sits as a parent; each operating unit becomes a sub-entity with its own invoice address, delivery addresses, and PO routing rule. At quote time, selecting the parent surfaces the full roster. A bulk import helper can ingest a school-district contact sheet or a corporate vendor list and create the parent + sub-entities + addresses in one pass.
Quotes land at the right billing contact, deliveries go to the right address, and Beth no longer has to confirm addresses with the rep for every multi-site order. The model scales — adding a new district stops being a special project.
A source list of the multi-site accounts (parent → site, billing contact, delivery address, PO routing) — a spreadsheet is fine — plus Odoo Contacts admin access. Carolina/Beth to validate.
When an audit request lands, the team rebuilds the audit format from scratch. The underlying data — lots, serials, end users — is the same as the monthly Tracings data, but the output shape differs, and the assembly is done by hand under time pressure.
Use the same underlying data model from the Tracings generator, plus a library of audit templates per regulator and per major customer. Given an audit request, the assistant pre-fills the relevant template; Kari validates and exports.
Audit responses go from days to hours. The stress of audit season is materially lower. Audit history is captured as a by-product, not as a separate filing exercise.
A few examples of past audit requests and their required formats, per regulator and major customer.
Pads and batteries expire on known dates. Today the expiry check is partly manual and partly done at the scene — meaning an inspector occasionally discovers an expired pad on the day of the visit, which results in a return trip and a customer follow-up email.
Two weeks before each scheduled inspection, automatically scan the inventory of supplies due to expire at that customer and pre-draft the pull list for the warehouse. Ops sees the list in advance, the warehouse picks the supplies, the inspector arrives ready.
Return visits drop by an estimated one to two per inspector per year. Customer confidence is materially higher because the visit is genuinely complete. Warehouse load is smoothed because picks are planned, not reactive.
Access to the inspection schedule and Odoo Inventory, plus confirmation of the two-week buffer window.
When the warehouse prepares supplies for an upcoming inspection, the pull list is built from notes and memory. There is no automated link from the inspection-schedule to the warehouse pick sheet.
Given the next inspection date and the customer's AED inventory, automatically generate the pull list, print the pick sheet, and book a warehouse pick slot. Oscar and Miriam receive the work as a scheduled task, not as a chase.
Inspections leave the warehouse fully kitted. The pre-inspection scramble disappears. The supply-expiry alert above and this generator together form the back-office side of a much smoother inspector day.
Odoo Inventory + Projects access, and ~20 min with Oscar/Miriam on how warehouse picks get scheduled.
Each new affiliate is set up as a vendor by hand on first payout. The monthly payout batch is recorded as bills individually. This is one of the more administrative Finance tasks and one of the most prone to small data errors.
On first payout, auto-create the vendor record (with tax-ID verification flow). On every monthly payout, auto-generate the bills in one batch. Carolina reviews the batch totals; the underlying records are already right.
Hours per month back to Carolina. Vendor data is consistent. New affiliates are payable from their first cycle, which is itself a retention signal.
Access to the affiliate-platform export/API and the Odoo/QuickBooks vendor API, plus your tax-ID verification step for new vendors.
When a refund or return runs through AliTrack, the corresponding affiliate commission has to be clawed back. Today this is done by hand, often a month late, which creates monthly reconciliation churn.
Sync AliTrack refunds into the affiliate platform on a schedule, identify the original commission, and apply the clawback in the same payout cycle. The affiliate sees the adjustment on the next statement, with the reason attached.
Affiliate-payout accuracy improves. Reconciliation between affiliate commissions and actual net revenue stays clean month over month.
AliTrack export/API access and affiliate-platform API access.
Once a renewal is paid, the AEDTS licence expiry date has to be updated in the AEDTS portal by hand, and the corresponding prescription document has to be generated and sent. Both are done manually, post-payment, by Kari.
Once the AEDTS API is available, the payment-received event in Odoo triggers an automatic AEDTS licence-expiry update and an automatic prescription generation. Kari is notified of the result and only intervenes on exceptions.
Closes the last manual step in the renewal cycle. Renewals complete the same day payment lands, not three days later when Kari has time to catch up.
A decision on AEDTS API access timing (currently queued behind HSI + SCE) — or a yes to the L2 interim where Kari one-click approves. This is the main blocker only you can unblock.