At ESN Santiago de Compostela, we were doing a great job at promoting events for exchange students, but we had an internal problem. All public communications were managed by a single team (ComCom), and it was hard to keep up with all the requests to publish the events that other teams (trips, cultural events, etc.) were organizing. We, ComCom, requested people to fill out a form with the event information and send it to us. Then we manually designed the promotional material and published it on our social media channels.
This process was manual, slow, and error-prone. I was convinced that we could automate this process and make it more efficient. That's how ComCom Manager was born. I developed a Slack bot that allowed any team to request the publication of an event by filling out a simple form in a Slack channel. Rather than having to go through a cumbersome process, the bot would communicate with the requester, ask for the necessary information, and then automatically forward the request to the ComCom team for approval and publication.
There was no need for manual intervention, and the process was streamlined. I built it using Express.js for the backend, PostgreSQL and TypeORM for the database, and Slack's API for the bot. The bot was able to carry out all the necessary interactions with the users, request the missing information, and ensure that the request didn't get lost in the process.
However, the project was not widely adopted by the other teams, as they kept relying on manual processes and direct interactions with the ComCom team. The lesson learned was that sometimes, even if you build a great tool, you need to ensure that the users are willing to adopt it and change their habits. I learned a lot by building the project, but I also saw how over-engineering a solution can lead to its failure if it doesn't fit the users' needs.