Odoo Helpdesk and Field Service implementation for teams that sell and deliver service
Many service businesses run tickets in one tool, dispatch technicians from a spreadsheet or calendar, track parts in a warehouse system and bill labor and materials in accounting software. Each handoff loses detail, and the customer hears about it. The Odoo Helpdesk and Field Service apps are Enterprise apps that bring ticket handling, field tasks, Inventory, timesheets and invoicing into one Odoo database. That shared data is what makes the design work worth doing, because a ticket, a visit, the parts used on it and the hours billed can all point to the same record. Teams usually implement these apps when they outgrow shared inboxes and manual dispatch, when they start selling service contracts with response targets, or when they need to bill field work accurately. The effort is mostly process design and data setup. Installing the apps takes little of the time. Most of the time goes into deciding how a request becomes a ticket, which team owns it, how SLA targets are measured, what a technician records on site, and when a completed visit becomes an invoice line.
Before the build starts, confirm your edition and plan. Odoo states that Enterprise is the paid edition with additional features and support, and that Enterprise source code requires a subscription or partner access. Odoo's pricing page indicates that only its Custom plan can be hosted on Odoo.sh or on-premise, so a self-hosted service desk depends on that choice. Ask the vendor or Odoo to confirm which apps are included in your subscription and how they are licensed for your user count. Those answers shape the rest of the scope. Next, map your service flow on paper. List the entry channels (email, portal, phone, forms), the ticket categories, the teams and their roles, the SLA definitions by contract tier, and the points where a job needs a technician visit. Then decide which stock items a technician may consume, which must be tracked by serial or lot, and who approves extra work. These decisions are hard to change once thousands of tickets and orders exist, so settle them with operations, finance and the service manager together.
The data work is the largest risk. Customer records, contact persons, equipment or asset lists, product codes, price lists and open contracts must be cleaned before import, because duplicates will appear on every ticket and every invoice. Plan a test database that is a neutralized copy of production, as Odoo documents for on-premise test copies, so that email, payment and integration settings do not fire against real customers during testing. Run several dry runs: create tickets, dispatch a visit, consume parts, record timesheets and invoice, then check that each figure matches across the apps.
Plan for maintenance from the start. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes, and security patches are only provided during standard support. Odoo 19.0 was released in September 2025 with standard support planned until September 2028, and Odoo 17.0 standard support ended in September 2026. Confirm the version you will deploy and its support end date against Odoo's support documentation, then budget for the upgrade path. Ask for a quote that separates the initial build, data migration, testing, training and any post-go-live support.
What Helpdesk and Field Service do inside Odoo
Helpdesk and Field Service share records with Sales, Inventory, Timesheets and Invoicing, so one request can become a ticket, a field visit, consumed parts and a billable line. Both are Enterprise apps, so confirm licensing before you scope the work. Menu paths and options change between releases, so check each area against the Odoo 19.0 documentation for the version you run.
Ticket teams and SLAs
Helpdesk groups incoming requests into teams, each with its own members, stages and routing rules. Service level agreements attach target response and resolution times to tickets, so a team can see which items are at risk before a deadline passes. For this implementation, decide how tickets are assigned, which customer or contract conditions select each SLA, and who is notified when a target is missed. Confirm how SLA policies, priorities and stage rules are configured in Odoo 19.0, because the available options depend on the release.
Field tasks and itineraries
Field Service turns a ticket or sales order into a task that a technician completes on site. Planning views sequence those tasks by day and by technician, which affects travel time, appointment windows and workload balance. Decide who dispatches the work, how customer address data is kept accurate, and whether technicians need offline access on the mobile interface. Confirm the planning, map and mobile options in the Odoo 19.0 documentation before you fix the dispatch process.
Worksheets for field evidence
Worksheets are structured forms attached to a field task, where technicians record what they checked, measured or repaired. They replace paper service reports and hold the evidence that a customer or auditor may request later. Define the fields for each service type, decide which values must be filled in before a task can close, and agree who signs off the record. Keep the form short enough for technicians to complete on site. Confirm how worksheet templates and their fields are built in Odoo 19.0, since the builder and its options depend on the release.
Parts consumed from Inventory
Parts used on a task can be recorded as stock moves from a technician's location, which keeps stock levels accurate and attaches material cost to the job. This depends on warehouse design: technician vehicles usually need their own stock locations, and the team must decide which products are tracked by lot or serial number. Agree also how returned and unused parts are handled. Confirm with the Odoo 19.0 documentation how parts are added to tasks and linked to Inventory operations, because this area affects stock valuation.
Timesheets for service work
Time spent on tickets and field tasks is logged as timesheet entries against the task or project, which feeds both cost tracking and billing. Decide who records time, whether travel is logged separately from work on site, and which rounding rules apply. Timesheet data can also inform dispatch planning. Wrong links between employee, project and task can misstate what is billed, so test one ticket from opening to invoice before go-live. Confirm timesheet and timer behavior in the Odoo 19.0 documentation for your release.
Invoicing of service work
Completed service can be invoiced from sales order lines, logged timesheets or task materials, depending on how billing is configured. Decide which services bill at a fixed price and which bill on time and materials, and when invoices are raised: on completion, on a schedule or at defined milestones. Accounting must agree on the tax and revenue accounts used for service products. Confirm the invoicing policies and the links between Sales, Field Service and Accounting in the Odoo 19.0 documentation before setting the commercial rules.
How a ticket becomes a field visit, a parts line and an invoice
The fastest way to see where an Odoo Helpdesk and Field Service project will succeed or fail is to follow one service request from the first customer message to the paid invoice. The example below is labeled illustrative and is not based on a client engagement. A customer reports that a refrigeration unit at one of its sites has stopped cooling, and the service company must dispatch a technician, fit a replacement compressor and bill for both the labor and the part. Each step creates or updates a record. A ticket, a field task, a worksheet, a stock move and an invoice line can all describe the same job, so the project team must decide which record is authoritative for each fact before configuration starts. If nobody makes that decision, the same fact will be typed in more than once.
The ticket lives in Helpdesk, where the team records the customer, the request type and the service-level target that applies under the customer's contract. Dispatch then converts or links the ticket to a Field Service task, which carries the scheduled date, the assigned technician and the site address. The technician completes the worksheet on that task, recording findings and the checklist the service company requires. When the compressor is fitted, the part should leave the technician's van location through Inventory, producing a stock move that Inventory owns. Confirm in your target version whether consumed products are recorded on the task, on the worksheet or on both, and whether the stock move is created from the task or from a sales order line. The answer changes who has to enter what.
Billing depends on how the service is sold. If labor is charged on a time-and-materials basis, the timesheet entries or service lines recorded against the task become the quantities that flow to the sales order and then to the invoice. If the visit is a fixed-price job, the task may only need a product line, and the timesheet becomes an internal cost record. Either way, the team must decide whether the sales order or the task holds the price, whether invoices are created from delivered quantities or from ordered quantities, and how a parts line added after the sales order is confirmed will be priced. Ask for the exact path to be demonstrated in a test database using your own pricing rules before any configuration is locked.
The handoffs are where data is most often lost or entered twice. The first is ticket to task, where descriptions, attachments and SLA dates may be copied by hand when they could be linked. The second is worksheet to stock. A technician who writes a part number in a free-text note creates no stock move, so Inventory and the invoice will disagree with the field record. The third is timesheet to invoice, where hours logged in one app are re-keyed into a sales line. The fourth is the customer record, which can exist in Contacts, on the sales order and on the ticket with different addresses or billing contacts. For each handoff, name one owner: Helpdesk for the request and its SLA, Field Service for scheduling and the completed worksheet, Inventory for every quantity that leaves a location, and Sales or Accounting for price and invoice status.
Before go-live, run the illustrative job end to end with a test customer, a van location, a serialized part and a test invoice, then check that each quantity appears exactly once across the apps. Confirm which roles may edit a completed worksheet, who may reverse a stock move, and how a cancelled visit is billed. Those answers set the access model and the reconciliation checks your finance and operations teams will rely on, and they are far cheaper to settle now than after technicians have started using the app in the field.
Which configuration decisions shape the Helpdesk and Field Service build
This table lists the five configuration decisions to settle before building Helpdesk and Field Service, with the options for each and the conditions that favor one over another. Read it as a checklist for the workshop that precedes configuration, since the answers determine which teams, stages, product flags and invoicing paths the build will contain.
| Decision | Options | Trade-off | When each option fits |
|---|---|---|---|
| Ticket teams and SLAs | One shared team with priorities, or separate teams by queue, region or customer tier | A shared team is simpler to staff and report on, but separate teams make SLA targets and escalation paths easier to enforce | One shared team fits a small support group with one service promise; separate teams fit contracts that promise different response levels to different customers or regions |
| Field work planning | Planning by itinerary (routes for a technician over a day), or planning by individual task | Itineraries suit dispatch-heavy work with travel, while task planning suits short jobs that can be done in any order | Itineraries fit mobile technicians covering a territory each day; task planning fits on-site jobs with fixed appointments or where the sequence of visits matters little |
| Consumed parts | Track parts from Inventory as stock moves on each worksheet, or record parts as text or service lines without stock movement | Stock-linked parts keep inventory and valuation accurate but add warehouse setup and van stock rules; text entries are quick but leave stock unreconciled | Stock-linked parts fit organizations that already run Inventory and need accurate counts; text or service lines fit low-value consumables that nobody tracks individually |
| Timesheets and billable service | Timesheets feed billing directly, or timesheets are kept for cost and reporting only | Direct billing ties invoices to recorded hours and needs clean time entry, while reporting-only time avoids billing disputes but leaves service revenue to manual preparation | Direct billing fits fixed-rate or time-and-materials contracts where hours are the billed unit; reporting-only fits flat-fee contracts or where service is billed by milestone |
| Invoicing approval | Automatic invoicing once work is marked done, or a review step by a named approver before invoices are issued | Automatic invoicing is faster but relies on correct setup, while an approver adds delay and a control point for disputed or large jobs | Automatic invoicing fits repeatable, low-variance jobs with tested pricing; an approver step fits regulated billing, new contract types or work with frequent variations |
Which Odoo edition and hosting plan you need before scoping
Before you scope an Odoo Helpdesk and Field Service project, confirm that you are buying the Enterprise edition and that your hosting plan can run it. Both apps are Enterprise applications. Odoo's Community edition is open source under LGPL-3.0, but the Enterprise source code is not publicly available and is only accessible through a subscription or partner access. A scope that quietly assumes Community features will leave gaps in ticket SLAs, field worksheets and service invoicing that you only discover during build.
The hosting choice matters just as much. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes custom modules and external API access. The One App Free and Standard plans are limited to Odoo Online. For this topic, that distinction shapes almost every integration decision. Field technicians often need data to flow to dispatch tools, mobile forms, ERP-adjacent systems or customer portals, and each of those connections depends on API access. Custom forms on worksheets or service templates may also need custom modules that the lower plans do not allow.
Ask Odoo to confirm, in writing, which plan includes Helpdesk and Field Service on your chosen hosting type, whether any of your planned integrations need external API access, and whether custom modules will be required. Also ask for the current per-user monthly price and the yearly discount that applies to your headcount. Technicians, dispatchers and agents may be licensed differently from back-office users, so list every role that will log in. Plan-level details and prices change, so do not budget from a figure you have seen in a document or a blog post.
The edition and plan decision also affects your long-term upgrade path. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Odoo SaaS versions are released every two to three months and cannot use extended support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. An on-premise deployment needs an Enterprise subscription for the upgrade service, and you should verify the current support windows for your target version before you commit to a go-live date.
Treat this check as a scoping gate. Record the edition, plan, hosting type, licensed roles and required API access in the statement of work. If any item is unconfirmed, the build estimate is not final. Your partner should be able to show how each Helpdesk and Field Service feature maps to the plan you have chosen, so that the first design workshop starts from a licensing position you have already verified.
Implementation sequence and the output of each step
The sequence moves from confirming how service work runs today to a tested Helpdesk and Field Service configuration that your own staff can operate after handover. Each step closes with a named record, so the decision to proceed is based on evidence rather than on the calendar.
Map service processes and agree SLAs
DeployOpen runs discovery workshops with your service manager, dispatchers, field technicians and finance contact. The team documents how tickets arrive, how they are triaged and routed, which service levels apply to which customers and contract types, how field visits and itineraries are planned, and where parts and billable hours are recorded today. The output is an approved process map and a written SLA definition listing each priority, its response and resolution targets, and the people who sign off exceptions. The step is done when your owners have signed both documents.
Prepare customers, equipment and catalog data
Your data owners clean and map the records the service apps depend on: customer and contact records, installed equipment and serial numbers, service products, spare parts and labor products, and the Inventory locations that represent vans, depots and customer sites. DeployOpen maps each source system field to an Odoo field and writes the rules for duplicates and missing values. The output is a data preparation workbook and a load file set, reviewed with your owners, with a count and sample check for each object. Migration of historical tickets is scoped here and may be a separate decision.
Configure helpdesk teams and field settings in test
In a test database, the team configures helpdesk teams, ticket stages, priorities, SLA policies, assignment rules and email aliases, then configures field service settings such as task stages, worksheet templates, itinerary behavior and the products that can be consumed on a task. Configuration is recorded as a configuration record that lists every setting, its value and the approver. Changes are made only in the test database and exported as a reviewed change list so production matches what was approved.
Connect Inventory, Timesheets and Invoicing
The team links the service flows to the modules that carry money and stock. Parts consumed on a field task should reduce stock from the correct van or depot location, timesheet hours should attach to the ticket and task, and billable service should flow to invoicing according to the agreed rules for contract, time and materials and warranty work. The output is an integration test script with expected results for each path, such as a consumed part, a non-billable visit and a partial invoice. Each result is recorded as pass or fail with the reason.
Set up user access and sign-in
DeployOpen defines roles for dispatchers, agents, technicians, supervisors and finance users, and limits what each role can read and change. Sign-in is configured with the method your identity team chooses. Odoo documents LDAP sign-in with optional user creation on first login from a template, Google Sign-In, Microsoft Azure OAuth, Facebook sign-in and two-factor authentication. Your team confirms which of these fits your identity platform and confirms the Enterprise or Community requirements for each. The output is an access matrix and a sign-in test record covering each role and each sign-in path.
Run test cycles with real tickets
Your dispatchers and technicians run a set of real tickets through the test database, using copies of recent cases with personal data neutralized. They follow the full path from intake to SLA timer, dispatch, field visit, parts use, timesheet, and invoice. Defects are logged with severity and owner, and each fix is retested. The output is a signed test cycle report that shows which scenarios passed, which were accepted as known limitations, and which remain open. Go-live proceeds only when the report has no open critical defects.
Cut over to production and hand over
The team schedules the production load, applies the approved configuration change list, loads the reviewed data files, and checks counts and a sample of tickets against the preparation workbook. Users are switched on in a controlled group, and hypercare covers the first working period of live use. Handover delivers a runbook covering daily operations, SLA monitoring, adding users and teams, backups and restores, and the Odoo version and upgrade plan. The step closes when your administrator has operated the runbook procedures in front of DeployOpen staff.
What drives Helpdesk and Field Service implementation effort and cost
This table lists the main factors that change the size of an Odoo Helpdesk and Field Service project and shows how to keep each one under control. Read each row as a lever: the driver, why it moves effort, and what you can decide before the build starts. Cost follows from the written scope, so use this list to shape that scope and the questions you put to any quote.
| Driver | Why it changes effort or cost | How to keep it under control |
|---|---|---|
| Ticket teams and SLA tiers | Each team needs its own stages, routing rules, assignment logic and SLA policies, and each SLA tier multiplies test cases for deadlines, escalations and breaches. | Start with the fewest teams that match real ownership, and define a small set of SLA tiers agreed with service leads before design. |
| Number of field users and mobile use | Field technicians need device access, offline expectations, mobile task flows and their own tests, and every additional role adds permission checks to verify. | Confirm which roles truly work in the field, pilot with a small group, and defer secondary roles to a later phase. |
| Depth of Inventory use for parts | Parts consumed on a service order draw from stock, which means locations, units of measure, serial or lot tracking and van stock must be set up and reconciled. | Decide which parts are tracked per job and which are simply billed, and reuse the stock design already planned for warehouses. |
| Complexity of billing rules for service work | Billable time, parts, fixed-price visits, warranty work and contract coverage each need pricing logic, invoicing paths and accounting checks. | Limit the first release to the billing cases that cover most jobs, and document exceptions as a later change request. |
| Custom forms or integrations with other systems | Custom worksheets, extra fields, and links to dispatch, asset or external tools need design, build, data mapping and regression testing. | List every required integration and form in the scope, and challenge each one against standard features before approval. |
| Data quality of customers and equipment records | Duplicate customers, missing contact details and inconsistent equipment serial numbers slow cleansing, import mapping and go-live checks. | Clean and deduplicate customer and asset lists before migration, and assign a named data owner on the client side. |
| Hosting and environment copies for testing | Each test environment needs its own database copy, configuration and sign-off cycle, and copies containing customer data must be handled under your data rules. | Agree how many environments you need, when test copies are refreshed, and how data is neutralized in non-production copies. |
How Helpdesk and Field Service connect to Inventory, Accounting and sign-in
Helpdesk and Field Service rarely work alone. Tickets, field tasks, parts, timesheets, invoices and user accounts all cross into other Odoo areas, and each crossing needs a decision before the build starts. The cards below describe the connections to plan, the sign-in options Odoo documents, and the checks to make against the version you deploy.
Parts and stock moves from Inventory
Parts consumed during a field visit or ticket resolution are normally recorded as stock moves in Odoo Inventory, so the technician's van or the depot location must exist as a stock location before go-live. Decide which products are tracked as parts, whether technicians hold their own stock locations, and how returned parts are received back. Confirm how the Field Service worksheet and Inventory interact in your version's documentation before you map warehouse routes.
Timesheets and Invoicing for service billing
Time spent on tickets and field tasks is captured through Timesheets, and billable time, parts and fixed-price work are turned into customer invoices through Invoicing. Decide which services are billed at time and material, which at fixed price, and which are covered by a contract or SLA, because each path produces different invoice lines. Confirm the billing options and the required app dependencies for your version against its documentation.
Posting to Accounting
Customer invoices and vendor bills created from service work post to the general ledger through the journals, taxes and accounts you configure for Accounting. Map the income accounts for service revenue, the expense or cost accounts for parts, and the tax treatment for each service type before testing. Confirm whether your edition's Invoicing app is enough for the posting you need, or whether full Accounting is required, against the version documentation.
Sign-in through LDAP
Odoo documents LDAP authentication, with the option to create a user automatically on first login from a template user. This suits organizations that keep technician accounts in a directory. Decide which directory group grants access to Helpdesk and Field Service, and which template defines the default access rights, because a new technician created from the wrong template can see tickets they should not.
Other sign-in options and two-factor authentication
Odoo also documents Google Sign-In, Microsoft Azure OAuth and Facebook sign-in, and two-factor authentication for user accounts. Choose one primary identity source for staff and confirm that the provider settings and any consumer sign-in options match your security policy. Confirm each option and its setup steps in the documentation for the version you run before you promise access to the field team.
Field technician access rules
Field technicians often need narrower access than dispatchers or agents: their own assigned tasks, their own timesheets and the parts in their stock location, but not other customers' tickets or invoice totals. Define these rules as user groups and record rules in the design phase, then test them with a technician account on a copy of the database. Confirm how your version's access rights and record rules handle portal or mobile users before you rely on them.
How upgrade windows change the timing of a service build
The version you build on sets the clock for the whole helpdesk and field service project. Odoo's documented standard support dates decide how long a configuration can run before you must move to a newer release, so the build plan should start from the version the system will live on, not the version that happens to be current when the project opens. According to Odoo's standard and extended support documentation, Odoo 20.0 was released in September 2026 with standard support planned until September 2029, Odoo 19.0 (September 2025) has standard support until September 2028, Odoo 18.0 (October 2024) until September 2027, and standard support for Odoo 17.0 ended in September 2026. A build started on 17.0 today would already be outside standard support, which changes the risk picture before any ticket team is configured.
Hosting type changes how that clock is enforced. According to Odoo's upgrade documentation, major version upgrades are mandatory every two years on Odoo Online and Odoo.sh, so the upgrade has to be scheduled as a recurring event with a test database, not treated as a one-off project. On-premise installations are not forced onto the same cadence, but the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. Helpdesk and Field Service are Enterprise apps, so an on-premise deployment that plans to upgrade through Odoo's own service needs the subscription in place for the entire life of the system, not only during the build. Security patches are provided only during standard support, which means a version that has moved past it is a security decision as well as a functional one.
Before the build sequence is fixed, ask three questions in writing. Which hosting type will the system run on, and does it match the plan that includes the Enterprise apps and any custom modules? Which major version will go live, and what is its standard support end date according to the current Odoo documentation? Who will run the upgrade test database, and when in the calendar will that happen relative to ticket volumes and peak field seasons? Build the SLA rules, field worksheets and Inventory integration against the target version, and record the version in the project's acceptance criteria. Confirm all dates directly in Odoo's support documentation at the time you sign, since release and support windows are published by Odoo and can be updated.
A practical planning check is to schedule the next upgrade before go-live. Choose a target version whose standard support runs well past your expected handover, then write down the date when that version's support ends and the date a test upgrade must complete to leave time for fixes. Custom modules for ticket routing or service report layouts need porting and retesting for each major version, and that work recurs. Ask any implementation partner to quote the upgrade test as a separate line item, and to explain what they will re-test on the upgraded copy, such as SLA timers, assignment rules, the parts consumption link to Inventory and invoicing of service work.
What teams ask before hiring help for Odoo Helpdesk and Field Service
What drives the cost of an Odoo Helpdesk and Field Service project?
Scope is the main driver. The number of ticket teams, SLA rules, service products, field technicians and sites changes the build, and so do the links to Inventory for parts and to Accounting for invoicing service work.
Who is paid for what: you pay for the Odoo subscription that licenses the apps and the hosting plan, and the implementation fee covers process design, configuration, testing, data preparation, training and go-live support. Subscription fees recur. Implementation is usually one-time, but ongoing support and upgrade work recur.
Integrations with other systems, custom reports and non-standard field workflows add effort. Ask any quote to itemize discovery, configuration, integrations, data migration, testing, training, go-live support and handover, and to state which items are one-time and which recur. DeployOpen does not publish prices. A quote follows from the written scope.
How long does a Helpdesk and Field Service rollout take?
Timing depends on how many teams, sites and workflows go live together and how quickly your decisions are made. Ticket routing, SLA definitions, field itineraries and worksheets each need a process decision before they can be built.
Parts consumption from Inventory depends on warehouse setup already being in place. Timesheet and invoicing rules depend on how Accounting is configured. Migrating existing tickets, contacts and equipment records can extend the schedule if the source data is inconsistent.
Ask for a written timeline that lists the phases, the client decisions each phase requires, the dates by which those decisions are needed and the testing window before go-live. No duration is given here because it depends on the agreed scope.
What does our team need to provide during the project?
Your team must make process decisions, supply data and give access. Expect a process owner for support, another for field operations and a finance contact for invoicing rules.
They supply sample tickets, SLA commitments, the service catalog, the technician roster, working hours, territories and sample worksheets. You also need test users who can run representative scenarios during user acceptance testing, and an administrator who can approve changes and grant production access.
Decide early on escalation paths and customer-facing notifications, because they affect routing and templates. Ask the partner to list each role, the time expected from each person and the decisions due at each milestone.
Can our internal IT team implement Helpdesk and Field Service alone?
Yes, an internal team can implement these apps alone if it has Odoo configuration experience, time for testing and ownership after go-live. The harder parts are usually cross-module design (helpdesk to field service to Inventory to Accounting), data migration, and testing of SLA timers and invoicing.
Teams without recent Odoo projects often underestimate the number of configuration decisions. A practical test is whether your staff can explain the setup, run a test plan and fix a configuration issue without outside help.
You can keep most of the build in-house and buy outside review for design, a fixed-scope build of the hardest modules, or a knowledge transfer phase. Decide early which parts stay in-house and which need outside review.
Do Helpdesk and Field Service require the Enterprise edition or Custom plan?
Helpdesk and Field Service are Enterprise apps, so they require an Enterprise subscription. On Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise. Only Custom includes multi-company, Odoo Studio, external API access and custom modules.
If your rollout runs in infrastructure you control, plan for the Custom plan. The Standard plan and One App Free are Odoo Online only.
Confirm current app availability, user pricing and subscription terms with Odoo before you commit, because the pricing page changes. Ask any quote to state which edition and plan its figures assume.
What changes at upgrade time for Helpdesk and Field Service setups?
Upgrades affect configuration, custom code and integrations, not only the database. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so the schedule is set by Odoo.
Odoo's upgrade service moves the database to a newer supported version through an upgraded test database, which should be tested before production. On-premise use requires an Enterprise subscription. The Community edition has no access to the upgrade service.
SLA rules, field worksheets, stock and invoicing configuration and custom modules must be retested after each move. Ask the partner to include a test copy process, regression tests for service and invoicing flows and a rollback plan in the quote.
Which Odoo versions are supported, and how does that affect planning?
Plan around the support window of the version you deploy. Odoo 20.0 was released in September 2026, with standard support planned until September 2029. Odoo 19.0 (September 2025) has standard support planned until September 2028, and Odoo 18.0 (October 2024) until September 2027. Odoo 17.0 standard support ended in September 2026.
Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Paid extended support afterward is limited to Odoo.sh for select versions and to on-premise. Security patches are provided only during standard support.
Confirm current dates on Odoo's support documentation before you choose a version, and set the upgrade date in the project plan from the start.
How DeployOpen scopes and delivers Helpdesk and Field Service work
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and Odoo Helpdesk and Field Service work follows the same path. We agree the ticket teams, SLAs, field tasks and billing rules in writing before any build starts, so the Enterprise app setup matches how your service operation runs.
How we scope
- Map ticket channels, teams, SLA targets and escalation paths before any configuration begins
- Confirm which Enterprise apps your edition and subscription include, since Helpdesk and Field Service are Enterprise features
- Agree in writing which Inventory, Timesheet and Invoicing flows for service work are in scope, with a fixed-scope agreement
How we build
- Configure ticket teams, SLA policies and field task stages in a non-production database first
- Set up parts consumption from Inventory and timesheet capture so service work posts correctly to invoicing
- Test with representative tickets and field jobs, and record the results against the agreed scope
How we hand over
- Deliver written documentation of teams, SLAs, worksheets, routes and billing configuration for your administrators
- Walk your dispatchers, technicians and billing staff through their daily screens and exception handling
- Provide a runbook covering backups, test copies and how to plan the next Odoo version upgrade
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to keep operating the platform
- Plan version upgrades around the Odoo support windows, since standard support runs three years after each major release
- Confirm with Odoo which hosting option, Odoo.sh or on-premise, your Enterprise subscription supports before you commit
