Odoo support from people who are on shift when you need them
After go-live, Odoo is the system your business runs on, and problems in it are problems in the business. Our consultants and developers work in shifts, so somebody is on whatever the hour is where you are, and a request gets a reply within hours. Functional questions, errors, wrong figures, slow screens, broken integrations and small changes, on every version from Odoo 10 up, Community or Enterprise.
What is happening?
Pick the one closest to it
Every request reaches a person on shift, at any hour, and gets a reply within hours. What that person does next depends on what kind of problem it is, and this tells you.
Incident
- Who picks it up
- A consultant first, and a developer alongside if the cause is in code or an integration.
- What to send
- What stopped, when, for whom, and a screenshot of any error. If you have the URL of the record, send that too.
- What happens
- It goes to the front of the queue. We confirm receipt, find the cause, and either fix it or give you a workaround so people can keep working while the fix is made and tested.
Functional support
- Who picks it up
- A functional consultant, and for anything in the accounts, a chartered accountant.
- What to send
- The report or screen, the figure you expected, the figure you got, and one example record.
- What happens
- We trace the figure back to the transactions behind it. Most of the time it is a configuration or a posting that needs correcting, not a bug, and we show you where.
Technical support
- Who picks it up
- A developer.
- What to send
- The full error text, what you were doing when it appeared, and whether it happens every time.
- What happens
- We reproduce it on a copy of your database, find the module responsible, and fix it there before touching the live system.
Functional support
- Who picks it up
- A functional consultant.
- What to send
- What you are trying to achieve in business terms, not which menu you think it lives in.
- What happens
- Usually a short call or a screen recording. If standard Odoo cannot do it, we say so and tell you what would.
Change request
- Who picks it up
- A functional consultant to scope it, then Studio or a developer depending on the change.
- What to send
- The process as it runs today, what should change, and who has to approve it.
- What happens
- We scope it, tell you whether it is configuration, Studio or code, and give you a plan before anything is built. Larger changes move to a customization project.
Performance
- Who picks it up
- A developer, with your hosting provider if it is infrastructure.
- What to send
- Which screens or actions are slow, at what times, and for how many users.
- What happens
- We measure before we guess: slow queries, heavy automated actions, reports over large tables, or a server that has been outgrown. Then we fix the cause we found.
Integration support
- Who picks it up
- A developer.
- What to send
- Which system, what stopped flowing, since when, and any error from either side.
- What happens
- Connections break when the other side changes. We find what changed, restore the flow, and replay whatever was missed so nothing is lost.
Migration
- Who picks it up
- A consultant to assess the database.
- What to send
- Your version and edition, and a list of anything custom.
- What happens
- That is a project rather than a ticket, and it has a page of its own. We start with an assessment of what carries over and what needs rework.
What support covers
- Functional support
- How do I, why did it, and what should I set. Answered by consultants who configure Odoo for a living, with finance questions going to chartered accountants.
- Technical support
- Errors, crashes, failing scheduled actions and modules that misbehave. Reproduced on a copy of your database, fixed there, then released.
- Integration repair
- When a payment provider, shop, bank feed or other system stops talking to Odoo, we find what changed on the other side, restore the flow and replay what was missed.
- Performance
- Slow screens, slow reports, slow nights. We measure before we guess, then fix the cause: a query, an automated action, a report over a large table, or hosting that has been outgrown.
- Small changes
- A field, a report column, an approval step, an automation. Scoped first, built in configuration, Studio or code, and tested before it reaches your users. Larger changes become a customization project.
- Maintenance
- Keeping third-party and custom modules working as Odoo publishes fixes, keeping test databases current, and telling you when a version decision is coming up.
- Upgrade planning
- An eye on the support window for your version, and an assessment when it is time. The upgrade itself is a project and has its own page.
- Hypercare
- The first 30 days after any go-live or upgrade we run, at no extra cost. Real volume surfaces things a test cannot, and we fix them as they appear.
Needs confirmation How support is priced (a monthly retainer, a bank of hours, per request, or a choice of these), and whether any response or resolution targets are promised by severity. Say what is true, or say nothing; a published target that is missed costs more than one that was never made.
How a request moves
The same path every time, so you always know where a request is.
You raise it
By email, WhatsApp or phone, whichever you prefer. It reaches a person on shift, not a form that files it for the morning.
We confirm and triage
Within hours you know we have it, what kind of problem we think it is, and who has it. Anything that has stopped work goes to the front.
We fix it on a copy first
Nothing is changed on your live system until it has been changed and checked on a copy of it. The exception is a configuration correction you can see on screen, agreed with you as we make it.
You verify
We show you what changed and you confirm it does what you needed. For anything touching the accounts, your finance team sees the figures before and after.
We close it with a note
What was wrong, what we did, and whether anything should change in how the system is used. Over time those notes become the record of your system.
How we touch a live system
Your Odoo is the business. These are the rules we hold ourselves to on it, and you can hold us to them.
Copy first, live second
Fixes and changes are made and checked on a copy of your database before they reach the system your people are using.
No edits to Odoo itself
We never change Odoo’s own code. Changes live in your modules or your configuration, so Odoo’s fixes and future upgrades still apply cleanly.
Every change written down
What changed, why, who asked and who approved. You get the record, and it is yours if you ever change partner.
Access that matches the job
Named accounts, the rights the task needs, and nothing shared. Removed when the engagement ends.
Our own people
The consultants and developers on your account are Growise Tech staff. Nothing is subcontracted, so the person who knows your system is the one who answers.
Taking over a system someone else built
A good share of our support clients came to us with an Odoo another partner implemented. We start the same way every time.
- An assessment, not a quote
- We read the database before we price anything: which modules are standard, Studio, third-party or custom; what is documented; what is fragile; what is unused.
- An honest verdict
- Whether what is there is worth keeping as is, worth fixing, or worth replacing. Sometimes the right answer is that the system is fine and only the support was missing.
- A stabilisation list
- The things that will cause the next incident if left alone, in order, with what each one takes. You decide what to do first.
Supported for clients
Needs confirmation
No cards until there are real support engagements to put in them. The implementation projects on the other pages are rollouts; under this heading they would read as support contracts they may not be.
Each card needs
- The client, or a descriptor we can use instead if the name is confidential
- What no standard Odoo app covered
- What we supported
- Which Odoo apps it works alongside
- The outcome, only where it can be verified
Worth asking about first
- Which clients are on ongoing support with us today, and since when?
- Which came to us with an Odoo another partner built, and what did the assessment find?
- Is there a client whose system we stabilised after repeated incidents, and can the before and after be described without numbers we cannot stand behind?
- Do any support clients span the Gulf and Pakistan, so that the shifts are the reason it works for them?
Common questions
When can we reach you?
At any hour. Our consultants and developers work in shifts, so there is always somebody on, and a request gets a reply within hours rather than days. Email, WhatsApp and phone all reach a person, and the Contact page has the numbers for Saudi Arabia and Pakistan.
Do you support Odoo you did not implement?
Yes, and a good share of our support clients arrived that way. We start with an assessment of the database so we know what is standard, what is custom and what is fragile before we take responsibility for it. That assessment is a small piece of work in its own right, and it is the right first step.
Which versions and editions do you support?
Every version from Odoo 10 upwards, Community and Enterprise, on Odoo Online, Odoo.sh or your own servers. If your version has left Odoo’s support window we will support it, and we will also tell you plainly what that means for fixes and security, and when an upgrade should be planned.
Will you change our live system directly?
Not without checking the change on a copy first. The one exception is a configuration correction you can see on screen, made with you and agreed as it happens. Code changes, module updates and data corrections are always tested on a copy before release.
What is the difference between support and a change request?
Support puts something back the way it should be: an error, a wrong figure, a broken connection. A change request makes Odoo do something it was not doing before: a new field, a new approval step, a new report. Small changes are handled within support once scoped. Larger ones become a customization project, and we tell you which it is before any work starts.
Is hypercare the same as support?
Hypercare is the first 30 days after a go-live or upgrade we run, included at no extra cost, when real volume surfaces what testing could not. Support is what follows it on an ongoing basis. The handover between the two happens on a planned date rather than by going quiet.
Can you also run our accounts in Odoo?
Yes. Bookkeeping, management accounts, payroll and tax compliance run inside your Odoo by chartered accountants is a separate service, for businesses already on Odoo. It pairs naturally with support, because the people keeping the system right are also the ones keeping the figures right.
What do you need from us to start?
Administrator access to the database, or to a copy of it; a list of the custom and third-party modules you know about; your hosting details; and the name of one person who can approve changes. If you do not know what is custom, the assessment finds out.
Other Odoo services
Build
Get Odoo in place and shaped to your business
Tell us what is not working
Describe the problem in business terms and we will tell you what kind of help it needs, who would pick it up, and what it would take. If your system was built by someone else, we start with an assessment.