Pre-Accounting CRM
In pre-accounting the problem is not that no record is kept but that the record sits far away from sales: the person who knows the balance and the person who puts through the new order do not look at the same screen. That an order has been opened for a customer over their limit is noticed after the goods have shipped.
The balance, the due date and the risk limit are fields on the customer record; an account over its limit is flagged as the order is opened. A payment promise is a dated task.
What we set up, and how
- Keep the balance, the due date and the risk limit as fields on the customer record and flag accounts over their limit in the list as the order is opened
- Record the payment promise with its date, so that customers who have passed the promised date gather in their own list and a follow-up task is opened
- Bring cheque and promissory note due dates together in one calendar and set an alert for the ones approaching their date
- Build up the invoice, delivery note and collection trail under the customer card and produce the month-end list for the accountant from there
| Account Card | The customer is an account record; the balance, the due date and the risk limit sit in its fields, and because the sales team looks at this card too, an overrun of the limit is visible at the moment the order is placed. |
|---|---|
| Payment Promise | A promise to pay is a task with a date; because the task does not close when the date passes, it stays in the list, and who took the promise is written on the record. |
| Cheque and Promissory Note Due Dates | Every cheque is a record with a due date field; the ones approaching their due date gather in a single list, and when it is collected the status field changes. |
| Accounting Program Connection | The mapping of the account and invoice fields is set up specifically for the project; there is no out-of-the-box module, the connection is made over the REST API and webhooks, and its scope is set out in writing at the discovery stage. |
In a company late collection does not begin with the customer failing to pay but with the promise being given without a record. The sentence "I will pay at the end of the month" stays on the salesperson's phone; the cheque that is coming due sits in a separate ledger; and the customer's total risk only becomes visible when the month-end account statement is taken. Because the three pieces of information sit in three separate places, collection turns into a job that depends on who called whom and when.
Rapitek CRM brings the balance, the due date and the payment promise together on the customer record; because the sales team looks at the same card, an overrun of the limit is visible as the order is opened. Since cheques and promissory notes approaching their due date drop into a list, following them up does not depend on remembering. We build the connection to the accounting program; there is no out-of-the-box module, and the mapping of the account and invoice fields is set up specifically for the project over the REST API.
What the plans cover and which items are priced separately are set out on the pricing page.
