How an open-source, Zoom chatbot can make time management more efficient
As a fully remote company, we have policies and procedures in place that help us to be more productive while fostering a positive and stimulating work environment. These standard procedures help us to be more aware of how projects are evolving and contribute to building cohesive teams.
One of these common procedures is the standup meeting. As part of a project we conduct daily standup meetings where we share status updates on our tasks, answering 3 simple questions:
- What did you do yesterday?
- What will you do today?
- Are there any blockers prohibiting you from completing your task?
Daily standup meetings are not just status updates for the manager or the product-owner, but help connect people, build trust within the team, and give team members an overall perspective of the project, all of which can be huge challenges for a fully remote team.
While the importance of these meetings cannot be underestimated there are potential pitfalls that can decrease the effectiveness of the daily standups. One of those pitfalls is what is known as a “never-ending meeting”. To avoid “never-ending meetings”, the team members should be limited to 1- 2 minutes per person, as this is more than enough time to answer the three questions we mentioned above.
How to optimise the time?
In order to keep daily standups short, it’s important that participants deliver concise updates. We’ve noticed, however, that there seems to be quite a bit of time wasted after each speaker finishes as there is indecision on who should speak next, and in a standup, with a lot of people that time adds up quickly.
In an effort to optimise the time we spend in our daily standups we decided to devise a creative solution to get rid of that awkward silence between speakers.
We began by considering the speakers’ sequence.
We identified 3 different ways to manage the speaker sequence:
- The meeting organizer calls the attendees to speak one by one. This is the classic solution as it, is easy for the host to keep track of the speaker sequence (for example by following the sequence of the speakers’ cams in the videoconferencing app), but this approach has a drawback. The host must intervene between each speaker to call out the next person in line which makes the meeting less fluid, reduces the team feeling between the host and speakers and basically turns the host into a master of ceremonies.
- Attendees decide when they are ready to speak and jump in when they are comfortable. This approach results in endless, awkward silence or confused overlaps when multiple speakers volunteer to share at once which reduces the focus and fluidity, and thus the effectiveness, of the standup meeting.
- Another approach is for each speaker to nominate the next as a sort of passing the talking stick of the Native American culture. Despite its historical roots, even this methodology has its downside. It becomes impossible to keep track of who has spoken and who has not, and, consequently, can end up breaking the focus and fluidity of the meeting as the speakers try to decide who should speak next.
After trying all three approaches with our teams we decided to develop a tool that automatically chooses the order of the speakers and shares it with the attendees. This allows us to have all the benefits of a frictionless meeting without the above-mentioned cons.
Automating repetitive processes is our mantra, and with that in mind, we created a Zoom Shuffle Bot that we have released as an open-source project.
How does the Shuffle Bot work?
Every morning when the meeting starts (we host our meetings on Zoom), the person who runs the meeting opens the Zoom chat and types in a simple
/shuffle command. Once that has been done, the Zoom chatbot finds the active meeting for the current user and returns the list of the attendees properly shuffled into a speakers lineup.
Sharing this list with the attendees using the in-meeting chat is enough to solve the problem.
Why build a Zoom Chatbot?
Zoom API offers a suite of possibilities in the marketplace. We can create up to 5 different application types:
The interesting one for our use case is the Zoom Chatbot type:
Zoom Chatbot is an application that can be installed in the account and interacts with the users via chat. The interesting part of this application type is the webhook features which provide a simple interface (the chat) and a way to track all the necessary events such as meeting joins, leaves and ends. This solution is the best fit for our needs.
Without further ado, let’s take a look at the journey we went through to build a Zoom chatbot in order to improve our standup meetings.
The Zoom chatbot application runs on fastify and consists of three endpoints running on a PostgreSQL database.
The three endpoints have different roles:
/authorize endpoint is used when you add this application to the Zoom account. After clicking it is added to the Zoom dashboard and you will be redirected to the authorized endpoint with a
code query parameter. The handler that responds on this route uses this code to get the token from the Zoom API and stores it in the database.
The other two endpoints
/bot are used every day when we use the Zoom chatbot.
Once an attendee joins a meeting, the Zoom’s webhook feature calls the
/hook endpoint passing the user_id and the username if the user is registered or just the username if it is a non-logged in user.
Our simple web service, made on top of fastify, upserts the meeting in the meeting table with the attendee info.
The usernames are properly encrypted using an aes256 algorithm to ensure privacy.
When an attendee leaves the meeting the
/hook endpoint is called notifying our app which removes the attendee from the meeting.
Doing this simple action we always have stored in the database a reflection of the current active meetings and the connected attendees.
/hook endpoint is also called when a meeting ends and helps us to remove finished meetings keeping our DB clean from stale data.
On the other side, a logged meeting attendee can get the shuffled attendee list just by going to the Zoom chat and writing the
/shuffle command. If the user is part of the attendee list the Zoom chatbot will answer with the expected response.
To do this the Zoom API calls out the
/bot endpoint passing the current user; our application receives the user who dispatches this command and searches the meeting that he/she is attending (in the attendees’ list) and once the meeting has been found it gets the attendees list, shuffles it and returns it as a message in the chat conversation.
Where did we deploy, and why?
This Zoom chatbot service was made on top of fastify and the heart of this application is deployed on Google Cloud Run by a Github Action CD pipeline.
The scale to 0 feature helps us to have a simple pay-per-use approach since the cold start doesn’t affect the usability of the application.
During the design of this application, we tried to avoid storing data. Privacy concerns were an important part of the POC development. The most obvious approach was to ask Zoom to give us the list of the attendees. Almost immediately we ran into a limitation in the Zoom API.
The API exposes 2 endpoints:
- The first one returns the list of the meeting registrants but is not certain that a registrant is an active meeting attendee. This endpoint requires that the user have administrator permissions since we want all teams to be able to use this application. This requirement makes this solution unenforceable.https://marketplace.zoom.us/docs/api-reference/zoom-api/methods#operation/meetingRegistrantGet
- The second option is to get the list of meeting participants using the “Get past meeting participants” but this assumes that the meeting needs to be finished and this makes this solution useless.https://marketplace.zoom.us/docs/api-reference/zoom-api/methods#operation/pastMeetingParticipants
Given these limits, we chose to store the data, in our case the attendees’ usernames are properly encrypted using an aes256 algorithm, enough to ensure that our requirements are being met.
We see our software as an evolving entity, the evolution comes from questioning what we did to being committed to a continuous improvement process.
As part of that evolution we are evaluating whether maintaining a PostgreSQL database is overkill for this kind of application and what the best alternative might be.
We have come to the realisation that storing tokens in the database is not the best approach. and are actively working on an alternative solution.? The app is still evolving so stay tuned for updates coming soon.
Eliminate the awkward silences
This was our journey on improving our standup and we are happy to share our experience and our tool with you. If you want to take a look, we are releasing the source code of this bot in this open-source repository , and if you like it, start eliminating the awkward silences.