Difference between revisions of "Back-end Processes"
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
=Back-end Processes= | =Back-end Processes= | ||
| − | + | These refer to internal processes run by the system. | |
==Notification processes== | ==Notification processes== | ||
| Line 7: | Line 7: | ||
The notification process runs once a day and scans all those tasks that need follow-up. | 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 | + | This process finds all the tasks about to expire and provides notifications for all the functions that have reminders configured for action, opportunities, events, and invoices. These notifications will appear on the dashboard each time the user logs in. |
| − | + | Notifications can be of two different types: | |
| − | + | Blocking notifications: This type of notification aims to guarantee compliance with the company's sales process. The user must attend to all the tasks that require follow-up to continue using the CRM. Otherwise, the system will close the session and prevent them from reconnecting. Although users can create these types of notifications, they are generated by the system automatically as a result of the said sales process. | |
| − | + | Non-blocking notifications: This type of notification seeks to remind the user about specific kinds of tasks or issues to consider during the sales process. Unlike the previous ones, these types of notifications are generally user-generated to facilitate their work. | |
| − | |||
| − | Non-blocking: | ||
==PARC== | ==PARC== | ||
| − | This process generates the opportunities and tasks | + | This process generates the opportunities and tasks to be carried out as part of the PARC Agreement. |
| − | It automatically creates the opportunity, inspection task, and follow-up. The corresponding dispatch is also | + | It automatically creates the opportunity, inspection task, and follow-up. The corresponding dispatch is also made and assigned to the team conducting the visits as part of the PARC. |
| − | + | Simultaneously, the system sends a summary to the account managers of all the tasks generated as part of a PARC agreement. | |
| − | This process runs weekly and the time these processes are generated can be fully | + | This process runs weekly, and the time these processes are generated can be fully customized by users with administrator permissions. |
==Batch Processes== | ==Batch Processes== | ||
| − | The following processes | + | The following processes don't require user interaction to work. These are automated. |
===Finance process - Past Due Invoices=== | ===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 | + | 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 voucher's creation date. |
| − | 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. | + | 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 | + | It does not have any notification. |
===Get contact Process=== | ===Get contact Process=== | ||
| − | This process creates a suppression list | + | This process creates a suppression list- a list of contacts to whom the company should send no more emails. The process reads all the contacts with an assigned email and whose status is "rejected" and adds them to the suppression list. |
| − | |||
| − | The process reads all the contacts | ||
| − | The objective is to avoid wasting time contacting | + | The objective is to avoid wasting time contacting clients who have already been approached with no success. |
===RPH Process - Nurture process=== | ===RPH Process - Nurture process=== | ||
| Line 51: | Line 47: | ||
This process begins once the state of an RPH is changed to "nurture P2". | This process begins once the state of an RPH is changed to "nurture P2". | ||
| − | When | + | When changed, the RPH automatically goes to a pool of dates and email templates to be sent as part of the nurture P2 process. |
| − | This process takes all the RPHs | + | This process takes all the RPHs in that pool, takes the corresponding template, performs the data replacement, and sets up the email. The system looks for the next template and updates the record with the corresponding number of days when the system should send a new email. |
| − | This process is repeated until all the templates | + | This process is repeated until all the templates- part of the Nurture P2 process- have been emailed. |
| − | + | If no response is received, the system will change the RPH status to "closed" due to inactivity. | |
This process runs once a day. | This process runs once a day. | ||
| Line 63: | Line 59: | ||
===Inbound/ outbound emails=== | ===Inbound/ outbound emails=== | ||
| − | This process is for reading emails. All emails, both sent from the CRM | + | 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 the system's backlog. |
| − | Through a security token the system reads the emails from the user's email account inbox. | + | 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. | + | 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 | + | This process is responsible for keeping all the emails sent between our advertisers and the Leads. |
===Bug detector=== | ===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. | + | 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=== | ===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. | + | 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= | ||
| + | |||
| + | *[[RPH]] | ||
| + | *[[Lead]] | ||
| + | *[[Accounts]] | ||
| + | *[[Contacts]] | ||
| + | *[[Opportunity]] | ||
| + | *[[Dispatch]] | ||
| + | *[[Invoices and Payroll]] | ||
| + | *[[External Portals]] | ||
Latest revision as of 17:25, 13 April 2021
Back-end Processes
These refer to internal processes run 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 provides notifications for all the functions that have reminders configured for action, opportunities, events, and invoices. These notifications will appear on the dashboard each time the user logs in.
Notifications can be of two different types:
Blocking notifications: This type of notification aims to guarantee compliance with the company's sales process. The user must attend to all the tasks that require follow-up to continue using the CRM. Otherwise, the system will close the session and prevent them from reconnecting. Although users can create these types of notifications, they are generated by the system automatically as a result of the said sales process.
Non-blocking notifications: This type of notification seeks to remind the user about specific kinds of tasks or issues to consider during the sales process. Unlike the previous ones, these types of notifications are generally user-generated to facilitate their work.
PARC
This process generates the opportunities and tasks to be carried out as part of the PARC Agreement.
It automatically creates the opportunity, inspection task, and follow-up. The corresponding dispatch is also made and assigned to the team conducting the visits as part of the PARC.
Simultaneously, the system sends a summary to the account managers of all the tasks generated as part of a PARC agreement.
This process runs weekly, and the time these processes are generated can be fully customized 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 voucher's creation date.
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 notification.
Get contact Process
This process creates a suppression list- a list of contacts to whom the company should send no more emails. The process reads all the contacts with an assigned email and whose status is "rejected" and adds them to the suppression list.
The objective is to avoid wasting time contacting clients who have already been approached with no success.
RPH Process - Nurture process
This process begins once the state of an RPH is changed to "nurture P2".
When changed, the RPH automatically goes to a pool of dates and email templates to be sent as part of the nurture P2 process.
This process takes all the RPHs in that pool, takes the corresponding template, performs the data replacement, and sets up the email. The system looks for the next template and updates the record with the corresponding number of days when the system should send a new email.
This process is repeated until all the templates- part of the Nurture P2 process- have been emailed.
If 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 the system's backlog.
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.
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.
