What is my application situation today? — Introducing better answers to Migri’s most often asked question step-by-step
At Migri, there is one main question that we our customers care about “When is my decision ready?” Together with other colleagues at Migri, Inland has worked to solve this challenge for over a year: Customers would love to get an exact date, when they can expect their decision, but Migri cannot give such for many reasons. One of the most obvious reasons is that the processing time depends on the completeness of the documentation and we only find out what is missing when we start processing the case.
More than a year ago we have introduced a processing time estimate, based on historical statistical data from the cases of the last 3 months within the same processing ground and application channel (online, on paper). This gives a general estimate about how long it general takes for a case to be processed. However, it does not tell anything about a particular application.
So, we rephrased the main question into “What is my application situation today?”. This can give a better understanding of the process to our customers. Again, answering this question is rather complicated. Customers who apply online already get an indication of their situation in our online application portal EnterFinland:
We hear in user feedback and interviews that customers are not satisfied with this solution: Often applications stay very long in phases 1 and 2, and then move within a day through step 3 to end up in 4. Changing this logic is currently not possible for many different reasons, including organisational and financial ones. So, to take this challenge one step closer to being solved we needed a different approach:
The idea
We cannot trace where the idea came up first, but Migri’s chatbot team ended up asking for our help in exploring the following idea:
What if we give customers a status number for their application, which changes depending on how many cases of the same processing ground are waiting for decision longer than this customer?
This number would decrease over time, reflecting that the case in question, is closer to being processed and gives an idea how long it may take until processing is started.
The second part of the idea was to use Migri’s chatbot Kamu to access this information. Users would input their case number to Kamu, and as a reply receive a visualisation of their waiting number. This is then also the first use-case where Kamu reads information from our internal case handling system UMA. We see the waiting number as a use case with lots of business-value, which is why it is the first one to be implemented.
The process of developing the logics
From January 2019 onwards, we started to look into how the logics should work in order to give the customers a realistic estimate of how many cases will be processed before their own, without raising false hopes. For this purpose, we needed to understand the logics of our processing and take a look at the data available to make such calculations. We chose five processing grounds as examples to test our logic against. The processing grounds were chosen from different units within Migri, some with short processing time estimates (students’ residence permit), some with longer (citizenship application of a person without a national passport) and some that included another processing organisation than just Migri (employed persons’ residence permit).
Next, a data scientist randomly selected 5 cases from 2018 for each processing ground and mapped how the waiting number would have developed for this case. We took data every 10 days, assuming that most customers do not check their case process daily, but about ones a week. The outcome from the data scientist looked like this:
Figure a: We received one long excel table with all cases included. (CaseID’s and dates are masked for security reasons
The table goes on for all the 25 cases we had selected at this time. In order to compare more easily what is happening in each case, we started to make visualisations of the waiting number over time.
We now went through several rounds of refining the logics: The basic rule always stayed the same: compare the current case to all other cases that are waiting for a decision longer than this case and have the same processing ground. However, we adjusted which cases to include: First, all cases that are in UMA and don’t have a decision, then only all cases from 2017 and 2018 and ended up with a rolling end date of 18 or 24 months. This means that whenever the user is requesting the waiting number, only cases that are not older than 18 or 24 months (depending on processing ground) are included in the calculations. The exclusion of older cases helped to make the data cleaner. Cases, which are in the system for unknown reasons but on which no decision will be made in the future, are now excluded from the waiting number calculation since they are of no concern for our customers.
In the process of refining the logic we also consulted our substance units and asked for their input.
The visualisation
The second line of work was around how to visualise the waiting number for our customers. The visualisation had to be easy enough to be understood and accurate at the same time. From the beginning we assumed, that simply giving our customers a number as part of a text would not be a good solution, since it would be very confusing (example: your waiting number is 354).
We made at least four iterations (1 paper based, 3 digital) before we decided on the visualisation option we will go live with. All three digital iterations were tested with users, first internally later at Itis in Itäkeskus and International House Helsinki with our real clients.
Based on the feedback we came up with the following visualisation, which we will go forward with:
It shows a timeline spanning from left to right. The left end is the day the application has been submitted, and the right the day of the decision of this application. In blue we see a number (389) indicating that there are 389 applications waiting for a decision in the same processing ground longer than this application. In general, this means that most of the 389 applicants, who have decided before this one, will get processed earlier. There is still some time to wait for this applicant. However, indicated by the line, the applicant can also see that she has already made quite some progress along the way and is already about 70% through the waiting time. The position of the blue line moves towards the right, as the application proceeds in the waiting line.
The name
Another topic of discussion was how to name the new service. Initially we started with queue number, but when interviewing clients, we realised that the expectation of a queue number in Finland is different: Customers expect to get a queue number, when waiting for a service in some office location (e.g. at the service desk of an organisation). Then the number they ones received would stay the same but increasing numbers would be called until their own is reached. But our number is different: The number decreases over time and when it’s very low the decision will be made.
During a brainstorming session with the chatbot team we went through many different options of names for the number we were working on for a while already. And we concluded that the best service name (for now) is “Waiting number” and “Odotusnumero” in Finnish.
The current status
The logic for the waiting numbers has been approved by Migris substance units.
The technical implementation is currently work in progress, but still requires a number of permissions. If our technical architecture proposal is approved, then the visualisation will be shown upon request to Migri’s chatbot Kamu. Users will need their diary number when they request this data.
We hope to introduce the waiting number concept for most citizenship and residence permit cases at Migri in the near future. We wish with this solution we are one step further to meet the expectations of the immigrants while balancing those with the realities of a governmental organisation.
Edited by Mariana Salgado
