When to create/answer a Presales ticket (New VS Existing customer)

You can distinguish in the next Cheatsheet the different cases that may apply regarding customer situation:

For new customers: Access to presales to estimate a feature they need. The sales person needs to create the presales ticket once the qualification is complete.

Existing customers without Success Pack: Access to presales to estimate a feature they need. The sales person needs to create the presales ticket once the need has been completely evaluated

Existing customer with an Ongoing Success Pack: No presales to be created. The FC will create the specification on the SaaS custo project and provide a more complete estimation of the time taken to develop the feature

Existing customer with an Expired Success Pack: No presales to be created. The FC in charge of the project will create the specification on the SaaS custo project to go negative on the Pack. If the customer purchases a new Pack, those hours will be deducted from the new Pack sold.

Other cases: Check with your manager to see what makes sense. Needs to be discussed case by case

Presales tickets need to cover a very specific question and not various business needs. If the customer has a lot of different non-standard requirements, we should sell a GAP analysis directly.

General

• Salesperson should be “Task Owner”, FC “Assigned To” and potential Tech “Reviewer”
• Presales is a point of contact between the Sales and FCs to ask
  • Advanced functional questions: very specific configuration (not present in existing resources), workarounds for a specific feature.
  • Estimates for an eventual development: the real need of the customer needs to be specified and analyzed by the salesperson before creating a presales ticket. We shouldn’t just transfer customers’ questions in the presales ticket.
  • The recommended size of the Pack that should be sold to a new customer. If you’re not sure about the number of hours to be sold to a client to implement its project.
• Presales process ensures a better quality of the projects sold by the Sales and less surprises for us when it comes to making our projects Success Stories.
• A new presales in the Pipe needs to have a clear, comprehensive, detailed business need in order for us to analyze it. If you think you don't have enough information, do not hesitate to challenge the Sales and ask them for more information
• Even in Presales, prioritize workarounds. If you think a feature can be covered in Standard and you're providing a convincing workaround, push that solution to the salesperson.
• Do the complete follow-up of the presales tickets on which you assigned yourself.
• Log all information on the presales ticket if there some discussions on Discord or on an external platform

General Workflow

Presales tickets contain 5 different sections:

• Context

  • Responsible: Sales
  • Provide practical informations about the customer / database

• Business Case

  • Responsible: Sales (validated by customer)
  • WHAT: Explain the need of the customer in terms of business; what does the customer want to achieve for their business, what is the extent of this need
  • WHY: Why is this feature necessary for the customer, what’s the implication of this development for the customer’s business
  • TIP: Create a presale when the business need is clear to you and when you’re ready to answer questions. Do not make any assumptions and do not copy/paste the information the customer gave you

• Functional Specification

  • Responsible: Functional Consultant
  • HOW: Explain how Odoo can handle the business need, what should be the modifications to bring in Odoo to make this development work, which models should be impacted, where should we add items / etc.
  • TIP: Use different types of support if needed to make things very clear (screenshot/video/other). The more information we have, the better we can estimate the development

• Technical Specification

  • Responsible: Technical Consultant
  • Technical Analysis: tech stuff
  • Dev hours: time to develop the feature (only on the TC side, develop the specific code)
  • LoCs: estimation of the Lines of Code required for this development
  • Estimation Reliability: Confidence we are putting in the evaluation of the time taken given the complexity / possible change requests
  • TIP: If the need isn’t clear, provide a conservative estimation to avoid any issue during the Sales process

• Total Estimation

  • Responsible: Functional Consultant
  • GOAL: provide a more comprehensive estimation given to the customer
  • Include not only the development time by the Technical Consultant but also the time taken for the functional analysis, testing of the dev, training of the customer on this specific development
  • Total: sum of all the hours taken for the development
  • TIP: The ratio to apply is going to be different for each kind of development. The smaller the development the easier it is to give a good ratio, don’t hesitate to provide a conservative estimation for:
    • Big developments
    • Modifications in the existing workflows
    • Reports
    • Presales that are not fully clear to you or the Sales

Different Stages

New

• This column is used for newly created tickets not completed by the Sales yet or on which you don't have enough information to provide a clear analysis (business need not complete, not clear or not explicit)
• If a ticket is not clear enough, get back directly to the Sales asking him/her for more details and explanations.
• The idea of this column is to have a complete overview of the business need of the client.

Functional

• This column serves 2 purposes
  • If a development is required, create a functional specification of the business need of the client. Do not get too technical but explain how you would see this new feature / modification in Odoo
    • Ex: Add a field on the Sales Order and add a button on the Sales Order to compute the tax amount and the number set in the new field
    • Or: Add 2 new M2O related to account.account on the product category and use those 2 accounts to generate this kind of accounting entry with the first field at the debit and the second at the credit (screenshot provided).
• If you can provide a workaround, a useful documentation that explains the solution or an estimate of the Pack -depending on the nature of the Presales- leave the ticket in the functional column waiting for the Sales' feedback. If the Sales has his question answered, put the ticket in "Done"
• You can start a technical specification if you feel confident with that but double check this with one of our amazing technical consultants if needed. If you start a technical specification, pass it to the column "technical" too.
• Put the ticket in "Done" once the Sales have their questions answered

Technical

• This column is mostly used by Technical Consultant. Given the business need and your functional specification, they'll be able to create a clear technical specification and provide a rough estimate for the development.
• Please make sure that you're reminding the Sales of the different ratios we apply (not only the development time but also the time for testing, etc.) The salesperson needs to communicate this info to their customers as well.
• Keep in mind that this is an estimation and do not hesitate to insist on that when communicating to the Sales. This is a broad estimation with a ratio of confidence on the development and certainly not a guarantee that the dev can be done in this amount of time and we are not commiting to this in the Presales workflow (or any other things related to dev in general for what it takes, it's impossible to do that)

General Guidelines

3rd party Apps

When it comes to 3rd party apps, 2 things can be done on our side depending on the customer’s willingness to pay for a code review and maintenance or not. This is importantant information as it will also determine if we are hosting their SH Repository (aka repo) ourselves or if the customer needs to host their database on their own repository. Please note that it’s not enough to link the 3rd party app. We need to understand exactly what they need in this 3rd party app so we can probably reduce the number of LoC of the 3rd party app if everything is not necessary. The goal is to avoid downloading a 2000 LoCs app (and make the customer pay maintenance for 2000LoC !) for 200 useful LoC covering completely the customer’s business needs. You can find the information about the number of the LoC of the modules in the Odoo App Store directly. Example:

• If the customer is ready to pay for the code review and maintenance
  • We can host the 3rd party app on our Odoo SH repository.
  • We’re going to do a complete code review of the code to make sure we understand what this 3rd party app does and what could be the potential impact of the additional modules. In general we’ll analyze this 3rd party app and re-create the features needed based on our own code. If we re-use some part of the 3rd party app code, we’ll bring modifications to it to satisfy our internal guidelines. The idea behind that is that we want to provide to our customers a custom code that is clean, clear and allows migration for the future. The expected cost for reviewing 100 LoC depends on different factors
    • XML LoC, generally for reports and views, is quite fast. You can expect more or less 10 min to analyze 100 LoCs
    • For Python / Javascript: this will depend a lot if this module impacts existing workflows of the database. The time may vary between 30min and 1h depending on the complexity of the code, its impact on the existing workflows or if the module adds a completely new feature in the system or not.
    • Keep in mind that those are only estimations ! Each module, such as ourselves, is different and generally needs a deeper investigation that could not be covered by a presales if the amount of time spent analyzing it is too important.
  • The maintenance costs will be computed depending on the number of Lines of Code (LoC) in the module. The fixed rate for those lines of code depends on the customer’s pricelist and the same rate will be applied than if we developed something ourselves.
  • If the customer agrees on paying for the code review, the maintenance and eventual modifications we’ll make to the module. This way, we’ll make sure that the 3rd party app will be maintained by us for the next upgrades of their database (upgrade from V13 to V14 for example).
  • Thus the one time and recurring fees for those 3rd party apps can increase very fast and maybe cost several times more than the initial cost of the subscription. As an example, the 3rd party app for the Shopify connector would require 9000/100*6$ = 540$ of maintenance cost per month, or 6480$/year.
• If the customer doesn’t want to pay for the code review and maintenance
  • We’ll not be able to do any development for this customer. We can help their Partner by doing Q&A with them but we’ll not develop that directly.
  • The guidelines for this are way more simple as we are not hosting their database on our own Odoo SH Repository. This means the customer needs to host their own repository.
  • We are not handling any part of the implementation of this 3rd party app. Your potential customer needs to get in touch with the Partner directly in order to receive some documentation and/or functional training to implement this part of the project.
  • We cannot commit at 100% that those features will not affect the Standard workflow of Odoo. If the customer encounters any issues that we cannot reproduce on a Standard database or on the Runbot, we’ll need to take more time to investigate their issues and this time will be billed to the customer. This part needs to be completely clear and communicated to the customer before the sale and appear on the project description when the project is sold.

Access rights

Modification of Access Rights should always be discussed in a Presales before selling a Pack. Access Rights are hard to modify in Odoo and every situation will be different depending on the customer’s needs. Access Rights’ complexity grows exponentially when customers want to make big changes in the existing Standard. Access Rights modifications can generally be challenged as it’s not impacting directly the customer’s workflows There are 2 major type of Access Rights modifications:

• Record Rules: restricting access to certain records via a matching field set on the user and on the model
  • Example: Add a field on the user to specify in which Business Unit he works and restrict the access to Opportunities / Sales Orders to this specific BU
• Access Right modification: Create / modify groups of access rights giving access to certain models / menu / features in the system.
  • Example: Create a new profile type that can only access the Assets in Accounting and not have access to invoices

Both of those modifications can take a lot of time both on development but also in testing. The ratios we’re displaying during the presales estimation need to be taken with a lot of precaution when it comes to Access Rights in general.

GAP/ROI Analysis

GAP/ROI analysis needs to be sold when the customer has a lot of requirements that can not be met in Standard.

Integrations

We need to separate integrations in two different types:

• We have an existing feature in Odoo that covers the need

We will not develop any integrations with systems providing features we can find in Odoo Standard (e.g. integration with Shopify / Prestashop / Xero Accounting / etc.). Odoo’s strength is based on the fact that all the applications are integrated out of the box and it doesn’t make sense to integrate our apps with a lot of different systems. Integrations can be made on our customers’ side if they have the technical expertise to do so as we are providing an API that they can use (you can find it here: https://www.odoo.com/documentation/14.0/developer/reference/addons/orm.html)

• We do not have an existing feature covering the integration’s need

If the customer wants us to do their integration, it should always be estimated with a GAP analysis as it’s impossible to provide a good estimation of the amount of time required to do it. A complete integration requires a deep understanding of their business needs, the relevance of information that need to be transferred, the format on which they store their data and a complete mapping of the fields between Odoo and their system to be integrated. It also generally requires some developments to add the fields missing in Odoo that we should integrate with the other system.