Eija Moisala and Lauri SaksiCustomer identification is critical for all companies. It enables organizations to improve services through personalization and relevant recommendations, but it also serves very practical purposes, such as ensuring that messages and invoices are delivered to the right person.
There are various ways to identify customers. Common methods include traditional username and password solutions, as well as one-time passwords (OTP) sent to the customer’s mobile phone. However, there are many situations where lighter authentication methods are not sufficient and strong authentication is required instead. Examples include purchasing on credit or ordering certain types of devices and services.
Several strong authentication solutions are available. In Finland, the most widely used methods are online banking credentials and Mobile ID (Mobiilivarmenne). Despite this, there are still many situations where customers are asked to present a physical identity document, such as a passport or an ID card. Most of us have experienced the frustration of being asked for identification only to realize that our documents were left at home.
This was also a common challenge in Elisa stores. Customers occasionally had to return home to fetch their identification documents before a transaction could be completed. It is surprisingly common for younger customers not to carry an ID card, while almost always having their smartphone with them.
To address this issue, we built a strong authentication capability that allows customers to verify their identity using only their smartphone, as long as they have bank authentication or Mobile ID in use.
Elisa’s ECC team started planning a Proof of Concept when the need for strong customer identification in Elisa stores was raised by Service Director Jukka Lehto. From the beginning, we knew we could leverage existing components that had previously been developed for Elisa’s corporate customer chatbot. A component-based and scalable service architecture had already been a guiding principle when the original Customer Service Identification solution was developed.
For the PoC, we decided to use an iPad placed in the store, allowing customers to scan a QR code directly from the device. Although it was clear from the outset that providing additional iPads to stores was not a long-term solution and that it would be better to utilize the stores’ existing secondary displays, using an iPad enabled us to move quickly and efficiently with the PoC.
Two developers from the ECC team were assigned to the project for two two-week sprints. The first sprint focused on solution design, preparation work, contacting the pilot store, and reusing the identification logic that had originally been developed for the chatbot within the Customer Service Identification component. The second sprint focused on implementation, QR code functionality, store piloting, and documenting the results.
Twenty customers participated in the pilot, all of whom had a need for strong identification. There were no errors, resulting in a 100% success rate. The sales personnel were happy about the solution and expressed their wish to have this in use as soon as possible.
With the PoC proving that strong customer identification in stores was technically feasible and well received by both customers and sales personnel, the next step was to evolve the solution into a production-ready service and expand testing beyond the initial concept phase. It took some time to get the pilot off the ground, but once the business and store teams were on board, the rollout progressed quickly.
Strong authentication in stores was not part of the sales portal software. It had existed as its own service behind clearly separated interfaces.
The solution required changes to two other teams’ code repositories, neither of which the developers had previously worked with. The first step was to understand how those repositories were structured and what coding style they followed. AI was used to accelerate onboarding rather than reviewing every repository and implementation detail manually.
The functionality originally built for the chat channel was a good foundation, but a few changes were needed. One capability had to be removed: generating a text link for the chat use case. Another capability had to be added: PDF and QR code generation for the store use case. Everything else stayed intact, including identity verification with a mobile certificate or online banking credentials, and returning the identification result to the caller.
In practice, this meant that instead of generating a link sent to the customer in chat, the service generated an instructional PDF containing a QR code. The sales rep starts the identification event in the portal, and the QR code is moved to the point-of-sale signature display. The customer scans the code with their phone, completes identification, and their details are automatically displayed on the sales rep’s screen while the sales rep can monitor progress throughout the process.
PDF generation was a completely new task for the developer, and AI helped draft it quickly even though final polishing was still done by a human. If this had been built directly into the sales portal without that separation, the identification logic might not have been as easy to reuse.
That same scope boundary also brought a clear benefit: because the authentication component was already production-ready, its reliability and security features carried over directly to the store implementation without separate development work.
At the same time, two practical improvements were added to the process: each identification now creates a clear event log that identifies the sales rep, store, and timestamp afterward, and customer details open in the sales rep view after successful identification.
Before production, two things were still uncertain, and neither could be verified anywhere except in a real store. Usability had only been tested with people who already knew the background of the solution, not with users who were new to it. PDF dimensions and resolution had also only been tested once on Store Support devices, never in an actual store environment. The AI-generated baseline was ready quickly, but the signature display dimensions and resolution created challenges together, so element sizes had to be adjusted manually.
The first test was conducted in a real store, with the developer acting as the test customer. The sales rep was only told that the feature was now available. He completed the entire identification process without any instructions or hesitation, as if he had used the feature before.
One small thing did not work as planned on the first try: the signature display was designed for showing contracts for signing, not other material, so moving the PDF there was initially a bit clumsy. This did not become a recurring issue, because it was a one-time adjustment, and customers still scanned the QR code and completed identification without issues.
The solution has now been rolled out across the entire store network and being used approximately 300 times per week.
The Strong Authentication in Stores capability has made the customer experience significantly smoother while maintaining a high level of security and compliance. It demonstrates how a modular software architecture can create long-term business value. We use the same principles when developing all of Elisa’s customer identity capabilities.
The components are scalable, reusable services that can be leveraged across Elisa, avoiding point-to-point solutions and enabling us to extend capabilities to new channels and services when needed. Identity data is centralized and available in real time, ensuring high data quality and privacy compliance when building new features.
While this project focused on strong identification in stores, the same identity architecture supports a much broader set of customer experience and business capabilities across Elisa’s digital channels.
This type of identity-driven architecture creates both customer experience and business benefits, including increased marketing permissions, improved data quality, proactive creation of Elisa IDs, richer multichannel customer journey insights, and stronger continuity of trusted customer data across services.
