General Description of the Feature

This feature deals with an enhancement during the process of a lead request via an external application. When a customer shows an interest for a vehicle then an inquiry is created in OneDealer.

  1. If the comparison (Name/Surname/email/phoneNumber) for the customer is valid with an existing business partner in onedealer then:
    1. A new inquiry has been created with status = in process
    2. A new lead has been created automatically after the validation for the BP 
  2. If the comparison is not valid (Name/Surname/email/phoneNumber) then:
    1. A new inquiry has been created with status = Interest Qualified
    2. Νo new lead is created

Rules

Stage 0 - Incoming parameters validation

  • The system validates that the requires parameters are provided
  • Validates that there is a valid dealer unit to assign the inquiry.

Stage 1 - Inquiry object creation

  • The system simply performs the inquiry object creation in the database (@IDMS_INQUIRY_BUFFER). This method takes care of assigning proper values to the necessary fields of InquiryType/InquiryInterest/AssignedUserid/dimensions etc.
  • It is important to understand that at the finalization of this stage, there is no "existing BusinessPartner code" assigned on the Inquiry object. In other words, the inquiry status will never be "PersonQualified" after the execution of this method finishes.
    • The only statuses that the inquiry can be in currently are Generated or InterestQualified.
      • The status "Generated" is the initial status of the Inquiry - there is no further logic for it.
      • The status InterestQualified means that the interest of the inquiry requires no manual validation via an employee - it is auto-validated. The decision of if an interest is auto-qualified or not, is based on a per-interest-type case.
        • Unknown - Generated
        • Service Appointment - Generated
        • ExternalDMSWithMultipleInterests (Incadea group ODIL specific interest) - Generated
        • BusinessPartnerRegistration (DADG productized logic, currently not used by anyone) - Generated
        • Stock Vehicle - Interest Qualified
          • This interest requires that the interest value is a vehicle code, native to OneDealer (it must exist in the XIS_Cars table). Based on this assumption, the interest is qualified - we do not require manual validation.
        • Smart Contract - Interest Qualified
          • The incoming inquiry is based on a stock list that is synced from the OneDealer vehicle list. We can safely assume that we already have the vehicle in the database and we do not require a manual validation.
        • Omnichannel Leasing Expiration Campaign - Person Qualified
          • The incoming inquiries are generated via the Omnichannel Campaign system. The audience list is based on Business Partner records that originated from the OneDealer OCRD records. As such, we do not require a validation/re-qualification of the BPs.
        • Kosmocar CRM - Qualified
          • see below "Kosmocar exception"
  • To summarize the above, if this step was executed successfully, we now have a inquiry object in the database, and a varying inquiry status, varying per case type. No other objects are generated (BP - Lead, etc.).

Stage 2 - Business Partner auto-qualification checks. This stage, is executed ONLY if the flag "AutoQualified" is set to True in the "Key relation" table.

  • In this step, the system uses a specific duplicate check rule that execute the following logic:
    • If a Company name is provided, then the rule searches for non-Vendor Company BPs, with the same name (OCRD.Name) as the provided one.
    • If the above fails:
    • The system searches for non-Vendor Private BPs, with the same FirstName and LastName as the provided ones, that also have at least 1 phone number (OCRD.Phone1 - OCRD.Phone2 - OCRD.Cellular ), being equal to at least 1 of the provided phones. 
  • If the above duplicate checks, finds no match/partial matches, then the method continues execution to the next stage.
  • If the check finalizes in an exact match, then:
    • The inquiry is updated with the correct BP fields (@IDMS_Inquiry_Buffer.U_IDMS_BP and @IDMS_Inquiry_Buffer.U_IDMS_ContactPrsnLo).
    • The status of the inquiry is updated, based on the following logic:
      • If the status before the duplicate check was "Generated", then it now changes to "Person Qualified".
      • If the status before the duplicate check was "Interest Qualified", then it now changes to "Qualified".
      • Unknown interest case type exception: The above logic can be simplified to "If an inquiry's interest and BP is known, then the inquiry is qualified and can be further processed to a retail lead/purchase lead/job card etc.". An "unknown" interest type, is by nature always "non auto-qualifiable", meaning that if we would follow this logic to the letter, an unknown inquiry would never be automatically converted to a lead, even if the BP is known. We have decided though to make an exception in this case and automatically set the status to "Qualified" instead of "Person Qualified" in the case of a successful duplicate check, allowing the next stages, to convert the inquiry to an "Unknown Interest" lead. However, in this case the "Make" code is mandatory to exist as part of the json information provided to the API.

Stage 3 - Validation Logic

  • In this stage, we execute validations before finalizing the processing.
  • At the moment only 1 validation takes place: Check if the BP's currency is active.

Stage 4 - Further Processing. This stage is executed only if the inquiry status is "Qualified".

    • In this stage, we have a proper inquiry object, filled with all the necessary information to automatically create a Business Process Entity (retail lead/purchase lead/job card/appointment etc.).
    • At the moment, this method only does the following:
      • If the case type is "Unknown" - "StockVehicle" - "VehicleSmartContract" (cases 0, 6 and 200 respectively), then a retail lead is created.


Kosmocar exception

An exception to the above is the Kosmocar CRM type. Due to hardcoded/very old logic, we had to distinguish the KosmocarCRM and Product logic. Contrary to the rest, the Kosmocar CRM type skips stages 2 & 3 & 4 and instead always tries to auto-qualify the BP and create a lead during stage 1 with custom logic, that we left untouched. It is not part of this description to analyze/document the logic of this method. If necessary, I can document it at another time.


Business Benefit

This feature helps the users for a faster lead's creation 


Configuration 

Inquiry Key relation

  • Auto qualification flag = Yes/No (on the level of the Inbound key)

Additional Information

  • Feature No.:  ODP-4461 - Getting issue details... STATUS
  • Test Case No.:  QA-3333 - Getting issue details... STATUS
  • No labels
Write a comment…