Government CRM
When the same citizen applies by letter, by phone and through the web form, three separate cases are opened inside the institution and all three move through different units. Which one was answered only comes to light when the applicant asks a second time.
An application is a record; its channel, subject and responsible unit are fields. Manual and workflow handovers are timestamped in the record's history; overdue applications gather in one list.
What we set up, and how
- Gather applications arriving by letter, web form, e-mail and WhatsApp into a single record structure
- Route an application to the right unit with assignment rules defined during setup, and see waiting and overdue work in one list
- Send notifications to citizens over SMS and WhatsApp, and leave a trace of the sending on the record
- Keep a dated history of the field changes users make on a record, for audit purposes
| Application Record | An application is a record; the channel it came in on, its subject and the unit responsible are in its fields; when the owner is changed by hand, by bulk reassignment, over the API or by a workflow, the handover, with its date and the previous and new owner, is written to the record's history; routing done by the assignment rules defined during setup is not currently written to this history. |
|---|---|
| Unit Routing | Routing is an assignment rule defined during setup; based on the subject field the record drops into the queue of the relevant unit, and work with no owner assigned stays on a list. |
| Response Time | The target date by which an application must be answered is a field on the record; applications approaching and past their deadline gather in lists filtered on that field. |
| Audit Trail | Field changes users make on the record are kept in its history, while the record's initial creation and some bulk updates the system makes in the background are not; which user changed what and when is read from the record itself, although for record deletions, automations and background processes the user shown in the history may not be the person who actually made the change. |
In a public institution, what decides the fate of an application is whose desk it lands on. When a document passes from unit to unit by hand, the days that go by in between sit on nobody's record; when the applicant asks about the status, which desk the file is on right then is found by asking around one person at a time. The duration of the work cannot be measured this way, and time that cannot be measured cannot be managed.
In Rapitek CRM an application is a single record: the channel it came in on and the unit it was assigned to are on the same card; when the owner is changed by hand, by bulk reassignment, over the API or by a workflow, the handover, with its date and the previous and new owner, is also written to the record's History tab. Thanks to the queue structure and the assignment rules defined during setup, an incoming request reaches the responsible unit without depending on one person's initiative; work that is waiting and work whose deadline is about to run out gather in a single list. The field changes users make on the record are kept in its history with who made them and when; the record's initial creation, routing done by the assignment rules, and some bulk updates the system makes in the background are not recorded there; for record deletions, automations and background processes, the user shown in the history may not be the person who actually made the change.
The scope of the plans and the separately priced items are written on the pricing page.
Other industry pages in the same area: Nonprofit CRM · Enterprise Cooperative CRM · Holding Company CRM · Franchise CRM
