TL;DR: Remote teams forget birthdays and work anniversaries because no one owns the remembering, and the founder usually gets stuck doing it badly. A simple Make.com workflow pulling from a Google Sheet and posting to Slack solves it permanently. The automation is the acknowledgment, not the opposite of it. Build the data first, automate second, and let the team add the warmth in the replies.
A teammate has a birthday today, and the 9am message that should mark it never goes out. Nobody was being cold. Everyone was heads-down in tickets. By the time anyone notices, the day has passed.
There’s nothing dramatic about that scene. The damage shows up later, as the slow erosion of the thing that makes a remote team feel like one. The wins office life used to deliver for free, like the hallway hello, the shared lunch, or the cake someone brought to a meeting, don’t have a remote default. They have to be built.
This is the workflow I built to fix that, and the reasoning behind it.
Remote teams lose the easiest culture wins by default
Recognition disappears when the structure isn’t there to carry it. Office-based teams used to get this for free. Hybrid and remote teams don’t.
The numbers are not subtle. A Moonpig study of UK adults found that roughly one in five employees has never had a birthday acknowledged at work, despite expecting it to be. A separate Yomly recognition report found that around 82% of remote workers report feeling unrecognized by their employers. theHRDIRECTORYomly
For small teams, the gap is worse. Most small businesses don’t have an HR function, which means the founder is the de facto remembering machine, alongside everything else they already handle.
You can’t out-discipline this problem. Trying to keep a mental list of eight or twelve birthdays plus work anniversaries plus quarterly milestones, while also running a business, is a system that fails every quarter.
Memory isn’t the fix
The honest answer is to stop relying on memory at all.
Forgetting happens at every level of seniority. The pattern shows up across company sizes because the cause is the same: there’s no system carrying the load. If you find yourself wanting to “try harder to remember” after a missed birthday, that’s the signal you need a system, not better intent.
Chapter 9 of The Self-Managing Business lands on this directly: systems that depend on memory fail, and systems that depend on willpower fail. The reliable ones build the reminders into the structure itself, so the structure tells you what to do at the moment you need to do it. The chapter goes deeper on how to wire that into your existing tools.
The same logic applies to any recurring task. I’ve written about this pattern in more depth in How to Build a Business System That Runs Without Motivation.
What I actually built
The setup is a Make.com scenario with four parts: a daily scheduler, a Google Sheet as the source of truth, a date comparison, and a Slack post.
The Sheet has three columns per person: name, Slack handle, and date (birthday or work anniversary). One row per event, so someone with both a birthday and a work anniversary appears twice. Every morning at 9am Logroño time, the scenario fires. It reads the Sheet, finds rows where the date matches today, and posts a message in the team’s #general channel.
I picked Google Sheets over a database because the team already uses Sheets daily. Some teams build a similar setup with a Notion database of employee birthdates and a daily scheduler that checks for month-day matches, but Sheets keeps the friction lower for a small team. Make Community
The message itself is short. It tags the person, names the occasion, and signs off with the bot’s name. No fake warmth, no GIF library, no automated cake emojis. The point is that the message lands consistently, not that it pretends to be a person.
This is the same approach I described in Task Master Workflow: Why Simple Automations Compound. A small automation that runs every day beats a complex one that runs sometimes.
Why automation is the acknowledgment
The obvious pushback is that an automated message feels less meaningful than a human one. In practice, the opposite is true.
A team that already trusts each other doesn’t lose anything when the bot posts the first message. The replies underneath it are still human. The GIFs, the inside jokes, the quick “happy birthday from the cat” voice notes all happen because the bot reminded everyone the moment was here. The automation does one job, which is to call the celebration into the room. The celebration itself happens in the replies.
The teams that get this wrong are the ones that treat the bot’s message as the whole gesture. The teams that get it right treat it as the prompt. Same automation, two different outcomes. What changes is what the team builds around it.
There’s also a quieter benefit. Nobody on the receiving end ever feels like they were forgotten and then almost-forgiven by a last-minute scramble. The message arrives on time, every time. Manual birthday tracking creates inconsistency and admin overhead, particularly for remote and hybrid teams, and inconsistency is what breaks trust. Motivosity
What recognition actually buys you
Recognition tracks directly to retention, which tracks directly to cost. Treating it as a feel-good metric misses the math.
Workhuman and Gallup research finds that regularly recognized employees are up to 10 times more likely to feel a sense of belonging at their company, and belonging shows up as one of the strongest predictors of whether people stay. Wellhub
For a small business, the cost side is brutal. Replacing a mid-level employee at a small company typically runs $30,000 to $50,000 once you factor in vacancy time, overtime, slipped client work, and the months a new hire needs to reach full productivity. FirstHR
A birthday automation isn’t going to single-handedly drop your turnover. But it removes one of the small, repeating failures that quietly tell people they’re easy to forget. Over a year, that’s twelve to twenty moments where the team felt seen instead of skipped. The broader version of this pattern, where the founder becomes the system and the system has a bad day every time the founder does, is what I covered in You’re the Bottleneck in Your Business Because Your Information Lives in Your Head.
Capture the data before you automate anything
Don’t start in Make.com. Start in the Sheet.
If you don’t have a clean list of every person’s birthday and start date, the automation has nothing to run on. Build the data first. Send a one-line ask in Slack: “I’m setting up something small. Reply with your birthday and your start date when you have a minute.” Most people will reply within a day. The rest you can chase.
Once the Sheet is reliable, the Make.com scenario takes about forty-five minutes to build for someone who’s used the tool before, and around two hours for someone who hasn’t. The reason to wait on automation is simple. Automating a bad dataset just sends wrong messages on time, instead of right messages late.
The same logic shows up in Before You Automate Your Business, Fix This First. Automation amplifies whatever it sits on top of. If the data underneath is patchy, the automation makes the patchiness public.
How the workflow improves itself
The first version doesn’t need to be the final one. Every run gives you signal.
After three months, I noticed the generic message I’d written felt flat for one-year work anniversaries. Birthdays were fine, but anniversaries needed a touch of specificity to land. I added a column for tenure-aware copy, and the scenario now picks between a few message templates based on whether the row is a birthday, a first-year anniversary, or a longer one. The retrofit took about twenty minutes.
That kind of small improvement is the whole point of a system you actually use. The pattern is the same one in How to Build an Issue Log That Actually Gets Used and How to Run a Weekly Improvement Review Without Turning It Into Another Meeting. You spot what’s not working, you pick one fix, you ship it, you move on.
The automation gets a little better each quarter without you having to think about it most weeks.
What I’d hope you take from this is the reframe, not the Make.com recipe.
Building a thing that remembers twelve birthdays a year frees up the attention you currently spend trying to remember them. That attention is better spent on the parts of running a team that actually need a human.
Frequently Asked Questions
You need three things: a place to store the dates, a scheduler that fires daily, and a channel to post to. The setup in this post uses Google Sheets, Make.com, and Slack. You can swap any one of those for an equivalent. Notion in place of Sheets, Zapier or n8n in place of Make.com, Microsoft Teams in place of Slack. The architecture is what matters, not the specific vendors.
Make the bot’s message short and let the team do the rest. Make a pool and randomize the output. Tag the person, name the occasion, sign it as the bot. Don’t try to write copy that sounds emotional. The replies underneath are where the warmth lives. The bot’s job is to start the thread, not finish it.
Ask before you add them to the Sheet. Some people prefer not to be celebrated at work, and the worst version of this workflow is the one that publicly broadcasts something they wanted to keep quiet. A single opt-in question during onboarding handles this for every new hire going forward.
Five people means five birthdays and five work anniversaries a year, so ten events. Manual tracking works for ten events until it doesn’t, usually when you’re traveling or sick on the day. The automation is most valuable precisely because it costs the same to run whether your team has five people or fifty.
About once a quarter, in my experience. You’ll need to add rows when new people join, remove rows when people leave, and occasionally tweak the message copy when something feels stale. None of that is heavy. Fifteen minutes a quarter is a reasonable budget for keeping it healthy.
… and even that bit can be automated.