Tisera CRM Omnichannel

Tisera CRM was built as an internal tool for a corporate group. It starts with the group's subsidiaries and is planned to be sold as a product later. Customer service agents reply to customers from WhatsApp, Telegram, and Gmail in a single inbox, and each subsidiary and each agent only sees the data they should see.

I was the Team Lead and also wrote code. I wrote the Software Requirements Specification, designed the database, and defined the code style. I also managed the team: I distributed tasks, reviewed the code, and reported to management.

Challenges & How I Solved Them

1. Requirements kept changing, and often arrived as a case rather than a spec Management usually gave me a business case, like "chats are not distributed evenly among customer service agents", and left the solution to me. With only 3 months, I could not build everything. I decided which features were worth building, negotiated the scope with management, and divided the work across the team. I kept the database design flexible so new requirements would not force a rewrite.

2. Designing a database for a large multi-tenant system for the first time This was my first chat application and my first multi-tenant design. I had to work out how to keep each subsidiary's data separate, and how to track which agent handles which conversation. I studied how chat systems store conversations, then designed the WhatsApp chat flow first, because it was the hardest one. That design became the base for the other channels. It taught me how to manage data per subsidiary and per agent.

3. Receiving messages from WhatsApp for the first time Messaging platforms send messages to a public address, but we were building on our own laptops. WhatsApp was still in Meta's sandbox, which made webhook setup the hardest part of the integration. I set up ngrok so the outside world could reach our development machines. I read the documentation carefully and tested step by step until messages flowed in reliably, then shared the setup with the team.

4. The team struggled to define the system flow Some team members had trouble turning the requirements into a clear flow of how the system should work. I sat down with them, designed the flow together, and shared references from my own experience so they could carry on independently.

How I Led the Team I translated what management wanted into clear tasks the team could act on. I also reported progress and discussed development decisions with management. I checked work before it was merged, to keep the quality and the style consistent. I stepped in when someone was stuck, whether on the flow design or the code itself.

Result The product was demoed to management and approved, even though development was still in progress. It gave me hands-on experience in leading a team, designing a complex system, and working with real messaging APIs.