Inside the STEMLink and Emojot Externship

What Problem Were the Students Asked to Solve?

A unified customer service platform solves the problem of fragmented conversations across WhatsApp, Instagram, Facebook, TikTok, web chat, email and SMS. Instead of support teams managing separate conversations across multiple channels, a single platform can bring customer interactions into one shared view.

A guest messages a hotel on WhatsApp about a late checkout. Nobody replies quickly enough, so she follows up on Instagram. An hour later she sends an email.

To her, that is one conversation. To the support team, it is three separate windows, three separate histories, and no reliable way to know they belong to the same person. She will be asked to explain her situation three times, and she will conclude, reasonably, that nobody is listening.

That is the problem in miniature. At scale it gets worse. Customers now arrive through WhatsApp, Instagram, Facebook, TikTok, web chat, email, and SMS, and they move between them freely. Support teams historically could not. Every channel meant another tab, another login, another partial view of the same person.

Emojot had an existing Customer Service AI platform, and it had fallen behind on two fronts at once. The interface no longer matched the company's current brand identity, which is the kind of problem that looks cosmetic. Underneath that, though, capabilities agents actually needed were missing outright. Fixing only the surface would have left the real gaps in place, and fixing only the features would have shipped something that looked nothing like the rest of the company's products.

So the brief was a rebuild rather than a repair.

Who Took on the Challenge?

Three STEMLink learners worked together on the Emojot project, taking on frontend, backend, team leadership and QA responsibilities. Their overlapping roles gave them experience of working as a small product team rather than in isolated technical roles.

Three STEMLink learners took it on: Lakshan Kawshalya as team lead, working across frontend and backend, Fasrin Rahman on frontend and backend, and Chanuki Fernando on frontend and QA.

The overlap in those roles is not an accident of the write-up. On a team of three building an entire platform, everyone touches the interface, someone has to own quality whether or not a QA function formally exists, and the line between frontend and backend engineer turns out to be far more porous than a job title suggests. That is a fair preview of how small product teams actually work.

They were placed with Emojot, an AI powered customer experience company founded in 2015. It is headquartered in San Jose, California and also operates from Colombo, Sri Lanka, which is what makes collaborations like this one possible for local learners. Emojot builds tools for customer experience management, online reputation management, social listening, and business process automation, serving hospitality, healthcare, retail, and banking clients.

The company describes its work as a unified intelligence system that connects experience signals across a business so problems can be caught and resolved in real time, on the reasoning that most organisations lose customers without ever learning why. By the time the problem surfaces, the customer has gone and the review is public.

That philosophy is worth noting, because it makes the brief coherent. A company built on connecting scattered signals cannot leave its own agents switching between seven apps.

What Did the Team Need to Build?

The team needed to build a unified customer service platform with a shared inbox, real-time messaging and channel configuration while keeping the AI component outside their codebase. The MVP focused on connecting WhatsApp, Instagram and Facebook and supporting the core workflows needed by agents and administrators.

The team did not start with code. They started with scope, and the most important early decisions were about what they were not building.

The AI was out of scope, deliberately. Emojot's AI Component is owned and developed by Emojot's own team. Rather than trying to build or replicate it, the students treated it as an external service reached through one clearly defined request. No AI logic, no retrieval implementation, no model code would live in their codebase at all.

That boundary is the single smartest call in the project. It means Emojot can upgrade, retrain, or replace the AI entirely without anyone touching the platform, and platform changes can never break the AI. It also meant three students did not spend their externship trying to out-engineer a specialist team.

Users came before features. Six distinct roles emerged, and the differences between them shaped everything. Super Admins are Emojot staff configuring the platform for a new enterprise client. Admins are the client's own administrators, managing agents and reading analytics. Support Managers own ticket queues. Content Managers maintain the knowledge base and the instructions the AI works from. Live Agents handle whatever the AI escalates. And End Customers arrive through whichever channel they prefer.

Features were split into three tiers. Critical for the first sprint, Advanced for the middle two, and Luxury for anything after. The minimum viable product was drawn tightly: a working unified inbox with real time messaging across WhatsApp, Instagram, and Facebook, plus a settings page for channel configuration, agent accounts, and departments.

The success test was equally concrete. A customer message arrives on WhatsApp, the AI processes it, and a reply reaches the customer. If that works end to end, the platform exists. If it does not, nothing else matters.

Analytics dashboards, sentiment indicators, push notifications, and AI confidence scores all appear in the feature list. All of them were excluded from the MVP. Writing down what you are not shipping first is how a small team finishes anything.

How Did the Students Design the Solution?

The students designed the platform as a layered system with an Angular dashboard, a backend of specialised services, a document database, caching and separate media storage. Messages from different channels are normalised into a common format so the rest of the platform can process them consistently.

The design is layered, and each layer has one job.

At the front is a single Angular dashboard containing everything an agent or admin needs: the inbox, the ticket manager, the settings, the workflow tools, and the analytics. It talks to one backend and nothing else. It never reaches the database, the AI, or a channel API directly, so that authentication, permissions, and logging apply consistently to every request without depending on the frontend to behave.

Behind it sits the backend, organised into services with clear responsibilities. Authentication, tickets, workflows, and notifications handle the business domain. A channel adapter normalises everything arriving from outside. A live agent service runs the real time connections. An AI service makes the call to Emojot's component. An outbound service sends replies back through whichever channel the customer used.

Data sits behind that. Conversations, tickets, users, and workflows in a document database, which suits the messy nested shape of a conversation thread far better than rigid tables would. A cache in front for the things read constantly but changed rarely. Separate storage for the images, voice notes, and documents customers send.

Two design decisions carry most of the weight.

Everything is normalised at the edge. WhatsApp, Instagram, TikTok, email, and SMS all speak different protocols with different payloads and different authentication. Rather than teaching every part of the system about all of them, incoming messages are converted into one internal format at the point of entry. Everything downstream sees the same shape regardless of origin. Adding an eighth channel means writing one adapter instead of changing the entire system.

The local environment mirrors production exactly. Every service runs in a container on a developer machine, and each one maps to its cloud equivalent. Only configuration values differ between the two. This eliminated cloud costs during development and, more usefully, meant the whole network topology could be validated locally before anything was deployed.

How Do You Turn an Idea Into a Working Product?

The team built a unified inbox where conversations from multiple channels could be managed in one place, with real-time messaging, AI-assisted responses and seamless human handover. They also added ticketing, conversation history, agent assignment and automated routing to support complete customer service workflows.

The inbox came first, because everything else hangs off it.

Conversations from every channel land in one list. Agents filter by channel, search by customer name or keyword, and sort by what needs attention. Every conversation carries a status of open, pending, resolved, or closed, and can be assigned to a specific agent. Each item in the list shows the contact name, the channel it came from, a badge marking it as AI handled, assigned, or unassigned, an unread count, a message preview, and a timestamp. An agent glancing at the queue learns two things immediately: what is waiting, and who owns it.

Messages arrive live with no page refresh, and bot messages are labelled clearly so agents always know who said what. A customer profile panel sits alongside with name, phone number, channel, and opt-in status. There is also a per conversation AI toggle, so an agent can switch automation off entirely for a sensitive or high value customer.

Then came the handover, which is where most automated support falls apart. The usual failure is that the AI does well until it does not, and the customer is asked to start over with a person who knows nothing about the previous ten minutes.

Here, the AI answers first with the full conversation context. Its response is stored along with the intent it identified and which specialised agent produced it, so the reasoning stays traceable. When a query exceeds what it can handle, the conversation is flagged and a live agent picks it up with the entire history already in front of them. A live indicator makes the handover explicit. Once resolved, the conversation can go back to the AI. Agents can also transfer between each other with full history moving instantly, which is what stops threads going cold at shift changes.

Ticketing followed. Some problems cannot be closed in a chat window, so any conversation can become a ticket with a title, description, priority, and department, staying linked to the conversation it came from. Tickets move through workflow stages, and every transition is logged with a timestamp, which gives supervisors an audit trail and gives the business something to point at when a customer disputes what happened. Because the AI already identifies what a customer is asking about, tickets can route to the right department automatically instead of being triaged by hand.

What Changed When the Problem Comes From Industry?

Building the platform for a real-world environment introduced challenges around duplicate messages, real-time connections, multi-tenant data isolation, expiring media, WhatsApp messaging restrictions and AI availability. The team had to design around these external constraints rather than treating them as theoretical edge cases.

Several problems in this system are considerably harder than the feature list makes them look.

Meta will send the same message twice if you are slow. Meta's systems expect a very fast acknowledgement when they deliver a message and will re-send if they do not get one, which means a slow response produces duplicate processing and, potentially, duplicate replies to the customer. The fix is to confirm receipt immediately and do all the real work afterwards in the background: normalising the message, calling the AI, storing it, and sending the reply. The customer sees none of it, and messages never duplicate.

One feature dictated the entire deployment strategy. Live agent handover needs a connection that stays open, so the backend has to run as a long lived process. That single requirement ruled out serverless hosting entirely, since serverless functions terminate after each request and cannot hold an open connection. A feature requirement determining infrastructure is a good example of how these decisions actually chain together.

Real time messaging breaks when you scale it. With one server instance, pushing a message to the right agent is simple. With several running behind a load balancer, an agent connected to instance one will never see an event raised on instance two. That has to be solved with a shared broadcast layer, or live messaging silently stops working at precisely the moment the platform becomes busy enough to need more than one server.

One client's data must never reach another. The platform serves multiple client organisations from one deployment, so every record is tagged to its organisation and every query is filtered by it automatically at the database layer. The important part is that this is enforced centrally rather than by trusting each developer to remember a filter on every query. One forgotten filter would leak one company's customer conversations to another.

Media expires before you can use it. When a customer sends a photo or a voice note, platforms like WhatsApp hand over a temporary link rather than the file. Those links expire. Anything not downloaded and stored permanently is simply gone, which means an attachment that mattered to a support case disappears from the record.

WhatsApp will not let agents message whenever they like. Free form replies are only permitted within twenty-four hours of the customer's last message. A tool that ignores this produces a bad failure: an agent writes a careful reply, sends it, and it silently never arrives. The platform tracks that window per conversation and shows agents its status before they start typing.

The AI can be slow or unavailable. When it is, the customer cannot be left staring at silence. A holding message goes out and the request is retried in the background, so a temporary problem on the AI side does not read to the customer as being ignored.

What Was It Like to Solve a Real Industry Problem?

The students had to turn an open-ended business problem from Emojot into a technical specification and working product. They also had to integrate with another team's AI service, conduct competitor research and identify genuine product gaps, giving them experience that goes beyond following a predefined classroom brief.

The requirements did not arrive fully formed, and that is the main difference from a classroom project.

Emojot posed a business problem. The team turned it into a specification, which meant asking questions, proposing an approach, and having that approach questioned back by people who run this platform commercially and know where such systems fail.

It also meant working with a boundary they did not control. The AI component belonged to another team and would keep evolving on its own schedule. That forced a discipline students rarely get to practise: agreeing a stable interface with another team and building strictly against it, rather than reaching into someone else's system because it is convenient.

The competitor research was part of that engagement, and it is unusually honest. The team studied four competitors, three of them Sri Lankan, and wrote down where Emojot loses as well as where it wins. Emojot is alone among the five in combining retrieval based AI, a multi agent AI architecture, ticket management, and analytics in one product. Every competitor already has an omnichannel inbox, so that alone differentiates nothing.

But two gaps went into the analysis unvarnished. Emojot does not support Sinhala or Tamil, including the transliterated Singlish and Tanglish that most Sri Lankans actually type on a phone, while two competitors do. And it is cloud only, which rules it out for government, defence, and other regulated clients who cannot host data externally, where two competitors can offer on premises deployment.

Telling the company you are working for where its product is behind takes a certain amount of nerve. It is also the only way research like that is worth anything.

What Did the Students Take Away From the Experience?

The technical list is substantial: API design, real time communication, authentication and role based permissions, multi tenant data modelling, caching, background job processing, containerised development, and integration against third party platforms.

The lessons underneath those matter more.

That external constraints are part of the design, not obstacles to it. The three second acknowledgement rule and the twenty-four hour messaging window were imposed by Meta, not chosen. Building around them properly, rather than pretending they did not exist, is most of what makes an integration reliable.

That scope discipline is what lets small teams finish. Deciding in advance that analytics, sentiment scoring, and confidence displays were not part of the first release is why the first release happened.

That boundaries between teams need to be explicit. Treating the AI as a service with a fixed interface meant neither team could break the other. That habit generalises to almost every engineering job.

That failure paths deserve as much thought as success paths. The happy path here is short. Nearly all the interesting work is in what happens when the AI is slow, when the media link expires, when the messaging window closes, or when a second server instance appears.

And that honest competitive analysis is more useful than a flattering one. Writing down that the product lacks local language support, in a document your client will read, is what makes the rest of the analysis credible.

What Did They Actually Deliver?

The team delivered a working customer service platform that brings conversations from multiple channels into one dashboard, supports AI-to-human handover, converts conversations into tracked tickets and keeps customer organisations' data isolated. The platform was taken through requirements gathering, design, implementation and testing.

The team delivered a working platform, taken through requirements gathering, design, implementation, and testing to a functional reviewable build.

What exists is a single dashboard where conversations from every channel arrive in one queue, where AI answers first and hands to a human cleanly when it cannot, where an agent picking up an escalation already has the full history, where conversations that need real work become tracked tickets with an audit trail, and where a business running multiple WhatsApp numbers across multiple branches sees all of them in one place while keeping each client's data isolated from every other.

Go back to the guest and her late checkout. In the version this platform replaces, she explained herself three times to three different windows and concluded nobody was listening. In this one, her WhatsApp message, her Instagram follow-up, and her email are the same conversation, in front of one agent who can already see all of it.

Why This Experience Matters?

There is a real difference between building an app and building inside an existing commercial product.

The second one comes with constraints you did not choose: a brand identity to match, third party platform rules to respect, agent workflows that cannot be redesigned away, a data model where one mistake exposes one company's conversations to another, another team's service you must integrate against but cannot change, and a real business that will maintain whatever you hand over.

Working inside all of that and still shipping something clean and functional is the actual skill. It is also the hardest thing to simulate in a classroom, where requirements are clear, scope is fixed, and a known answer waits at the end.

That is the point of industry-focused learning: not simply preparing learners to enter the technology industry, but giving them a chance to experience it before they do.