Call center operators use our dispatching solution to identify request types and locations and to redirect them to help coordinators who are able to process these requests. This way, coordinators will only receive requests that they can handle.
Any organization can easily be integrated into the dispatcher system by being registered as a coordinator for a specific place or service. They remain free to accept any request or let it pass. Once a request has been accepted by a coordinator, all others are informed that it is being taken care of.
Users don’t need to know in advance who is able to process their requests. They only need to know a single hotline phone-number, where operators using our dispatching solution will connect them with people coordinating help.
A bird’s-eye overview
Design goals
Ease of use and integration
Our primary goal is to support existing operations, not to replace them or compete with them. Users only need to know a single number. Being integrated as local coordinator is a very simple process (despite safety measures), one then receives requests via our telegram bot. We can also accommodate other endpoints for coordinators, if desired. Below you find three examples of real requests for accommodation and translation as received by a coordinator through telegram, two of them taken by some other coordinator.
Information Security
As the system is being used during a war, we expect to be attacked. Therefore, we don’t save any sensitive data and participants in the system don’t know more than they need to. Different coordinators don’t know about each other, nor do call-center operators know each other or the coordinators who receive processed requests. Volunteers performing on-the-ground operations and users are not saved in our system at all.
General applicability and scalability
We understand that such a dispatching system can be used in many situations when volunteer work or coordination of different parties is required, not just during the current crisis. Therefore we focus on ease of reproducibility and deployment, rely on open source technologies and plan to make the dispatcher openly available in the near future. Pavel and Mischa were very surprised to find that no such solution currently exists, and we want to fill that gap.
📝 A note on roles and people (examples)
The mapping between roles and the people who fill them is many-to-many and extremely flexible. Each role can be filled simultaneously by individuals, small groups, or entire organizations. A hospital could ask for help by phone (therefore be a user), the role of phone operator could be filled by a specially hired call center company, a volunteer center could play the role of local coordinator which passes tasks on to volunteers, and so on.
It is even possible for a single person to take on multiple roles. As an extreme example, one person, say Alice, could take on all roles simultaneously. Imagine that Alice is able to distribute medical supplies in Kharkiv and thus is registered as a local coordinator. She also has enough time to take calls and function as a phone operator. Being only one person, she distributes the supplies by herself, thereby also taking on the role of the volunteer. As a user (person in need), she might call the system to ask for delivery of specific supplies that are running out in her personal storage.
In the above example, Alice fills every single role by herself. The only thing she needs to remember is that while she is working as phone operator, she should forward requests through our system, even requests that she as local coordinator could take on herself. Our system takes care of selecting the most suitable coordinator for a request. If this turns out to be her, she will be notified through the system’s separate local-coordinator interface (currently a telegram bot).
💡 Integration into existing systems and helper communities
There are many groups and systems of all kind that aim at providing different services to those in need. Our dispatching solution can make existing systems more effective without competing with them nor replacing them. We address this design goal by two means:
- Support of the crawling operator role, a human who searches channels for help requests and processes them through our system of coordinators and volunteers. Existing crawling communities only need to read a minimal instruction on how to interact with our system to get started.
- Local coordinators are only very loosely linked to our system. Volunteers are still only in contact with their coordinators and remain completely disconnected from our system. Any existing local organization can “plug in” to our dispatching system by registering a local coordinator and reading a small tutorial on our user interface.
We hope that this will be a service which can (1) directly help those in need and (2) help other services to coordinate their efforts by providing a centralized phone line and a clear workflow.