Odoo's Mergebot
93f02129b8
RATIONALE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS: TEAM ALLOCATION
Team assignment has to be updated as we may have team domains that overlap.
We therefore remove maximum number of leads to allocate to teams. Instead all
available unassigned leads are allocated within teams.
- Solution: assign all available leads and not a count based on team's
capacity. This notably reverts the main goal of odoo/odoo@6df2f0c
(see odoo#48422)
This assignment process is done proportionally to the team capacity. It is
computed as the sum of each member's maximum assignment counter. This means
that with a team having twice as much sale capacity than another team sharing
the same domain: first team should receive about 2/3 of leads while the second
one should receive the remaining 1/3.
- Solution: assign lead one by one. Choose a team randomly using a weighted
random algorithm, based on team's members capacity.
SPECIFICATIONS: MEMBER ASSIGN
Counting every lead whatever its state may lead to an inconvenient situation.
Moreover salespersons may opt-out from assign by setting their max capacity
to 0, for example when going on holidays.
When doing that lead assignment is not smooth and getting back to a full
pipe may take several days. To solve that issue a compensation is added in
assignment quota done to sales people. Salespersons having few leads will
get a boost in assign as soon as they get back in assign process. When being
near maximum compensation is nearing 0 and daily quota is given.
ENSURE SALES PERSONS PIPE FILLING
Counting every lead whatever its state may lead to an inconvenient situation.
If a salesman always reaches its maximum every days he will always receive the
number of lead he got 30 days ago. For example if the salesman goes in holidays
for few days and set the max to 0 he receives no lead during his vacation.
Then after a few days of assign he reaches its maximum and receive 0 leads
for a few days. This leads to having windows of leads that repeat themselves
every 30 days.
* Solution: do not limit at maximum capacity anymore. Compensation is voided
if limit is achieved. However asked assignment is done. Salesman could
receive more than its max capacity but 30 days window ensure old leads
are regularly going out of count.
``assignment_max`` is now more a mean target of leads to be assigned during
a 30 days window than a real maximum capacity. Field is renamed accordingly.
WORK DAYS / CRON TIME CONFIGURATION
When running the cron is should assign leads based on its frequency. If cron
runs once every day, work_days given to sub methods should be 1. If it runs
more than once day it should be less than 1. We therefore remove the *2
multiplier and support fraction of days.
As assign process changes in this merge, assigning more strictly compared to
salespersons capacity will not be an issue anymore. Assign process is best
designed to run every few hours (~4 times / day) or each few days. Code and
work_days are updated accordingly.
PERFORMANCE
During team assignment setting team on leads one lead at a time may cause
performance issue. As PLS is computed at each flush we want to flush after
a bunch of lead. For that purpose we need to avoid too much commits and
also avoid to search for duplicate at each assignation.
We therefore perform the search for duplicates before going into allocation
and use a cache through loops to ease using pre-fetched information.
Unlinking duplicates at each iteration is also sub efficient as it causes
recomputation or invalidation. We therefore aggregate all duplicates to
unlink and unlink them in the main team-based loop instead of the sub loop
that is lead-based.
LESS AUTO COMMITS
During team assignation, assigning lead one by one may cause performance issue.
Since PLS is computed at each flush, so we want to flush after a bunch of lead.
To solve that we obviously need to not commit at each assignation but
also avoid to search for duplicate at each assignation, that why the
search for duplicates is done at the beginning of the process and stored
in memory.
ASSIGN WON / LOST LEADS USAGE
In this merge we also
* use stage instead of probability to exclude won duplicated leads in order
to include leads with 100% but still not won;
* count all leads in lead_month_count used in assign to effectively compute
sales persons workload;
* keep team when assigning and deduplicating leads instead of erasing
master opportunity team;
* crm: correctly filter out won and lost leads for assignment using
stage;
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
closes odoo/odoo#70723
Forward-port-of: odoo/odoo#70664
Forward-port-of: odoo/odoo#70172
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials