Difference between revisions of "Back-end Processes"
Line 78: | Line 78: | ||
Every 30 minutes the system scans the database searching for all those jobs (dispatches and tasks) with a 3 hours delay. Then it sends an alert to a designated list of users with either the owners or managers for the job. | Every 30 minutes the system scans the database searching for all those jobs (dispatches and tasks) with a 3 hours delay. Then it sends an alert to a designated list of users with either the owners or managers for the job. | ||
− | |||
− | |||
=Quick Access= | =Quick Access= |
Revision as of 12:00, 14 January 2021
Back-end Processes
Internal processes ran by the system
Notification processes
The notification process runs once a day and scans all those tasks that need follow-up.
This process finds all the tasks about to expire and all the tasks that have reminders, that is, the reminders that have been configured for both tasks as well as opportunities, events and invoices.
These notifications will appear on the dashboard each time the user logs in.
In addition, notifications can be of two different types:
Blocking notifications: the user must attend to all the tasks that require follow-up in order to continue using the CRM, otherwise the system will close the session preventing them from reconnecting. The objective of this type of notification is to guarantee compliance with the company's sales process. Although these types of notifications can be created by the users, in general they are generated by the system automatically as a result of said sales process.
Non-blocking: this type of notification simply seeks to remind or give notice of certain types of tasks or issues to take into account during the sales process. It is important to clarify that, unlike the previous ones, these types of notifications are generally generated by the users as a way to facilitate their work.
PARC
This process generates the opportunities and tasks that must be carried out as part of the PARC Agreement.
It automatically creates the opportunity, inspection task, and follow-up. The corresponding dispatch is also created, so that it can be assigned to the team that will be conducting the visits as part of the PARC.
At the same time, the system sends a summary to the account managers of all the tasks that were generated as part of a PARC agreement.
This process runs weekly and the time these processes are generated can be fully customised by users with administrator permissions.
Batch Processes
The following processes don’t require user interaction to work. These are automated.
Finance process - Past Due Invoices
This process takes all the invoices with a debt greater than zero and performs a validation of the days corresponding to the payment terms and the creation date of the voucher.
This process takes those payments owed, calculates the corresponding penalty and updates the payment records so that the corresponding user can control and monitor them.
It does not have any type of notification.
Get contact Process
This process creates a suppression list, that is, a list of contacts to whom no more emails should be sent.
The process reads all the contacts that have an assigned email and whose status is "rejected" and creates a list with them.
The objective is to avoid wasting time contacting potential clients who have already been contacted with no success.
RPH Process - Nurture process
This process begins once the state of an RPH is changed to "nurture P2".
When it is changed, the RPH automatically goes to a pool for which the dates and templates of the mails that must be sent as part of the nurture P2 process are established.
This process takes all the RPHs that are in that pool, takes the corresponding template, performs the data replacement and sets up the email that should be sent. Then look for the next template and update the record with the corresponding number of days in which a new email should be executed.
This process is repeated until all the templates that must be executed as part of the Nurture P2 process have been sent.
In the event that no response is received, the system will change the RPH status to “closed” due to inactivity.
This process runs once a day.
Inbound/ outbound emails
This process is for reading emails. All emails, both sent from the CRM, and sent and received through other email service providers are saved in a backlog of the system.
Through a security token the system reads the emails from the user's email account inbox.
Every time you read an email, it creates a data table within the CRM, and in turn establishes a tag for those emails sent from the CRM.
This process is responsible for keeping all the emails sent between our advertisers and the Leads, for instance.
Bug detector
It is a process that runs daily looking for errors. This process sends the CRM administrator a report with the system errors found.
Expired Jobs
Every 30 minutes the system scans the database searching for all those jobs (dispatches and tasks) with a 3 hours delay. Then it sends an alert to a designated list of users with either the owners or managers for the job.