Every company I've worked with has the same graveyard: a folder of HR tools nobody opens. The attendance app with three logins last quarter. The leave tracker everyone forgot the password to. The payroll portal the ops person logs into alone, once a month, dreading it.
The tools weren't bad. The problem was simpler and harder: people didn't use them.
When we started building Tickin, we kept circling back to that. Not "how do we build a better HR dashboard" — there are hundreds of good ones — but "why does nobody open the ones that already exist?"
The answer was boring and obvious. Your team already spends all day in one place: Slack or Microsoft Teams. Every tool that lives somewhere else is a context switch, a new tab, a login, a thing to remember. And humans are very good at not remembering things that aren't in front of them.
So we made a decision that shaped everything after it: don't build another app. Build where the team already is.
What "inside chat" actually means
It's easy to say "we integrate with Slack." A lot of tools mean "we'll post a notification there and then make you click out to our website." That's not what we wanted.
We wanted the whole loop — the action and the result — to happen inside chat:
- An employee types
/tickin startto clock in. They get a reply in the same thread. No app opened. - They request leave with a command or a button. Their manager approves it with a click, right in Slack or Teams. The balance updates on its own.
- Payslips arrive as a direct message. Overtime, reminders, end-of-day updates — all in the chat they're already reading.
The admin still gets a full dashboard for payroll and reporting, because some things genuinely need a bigger screen. But the 90% of interactions that employees do every day never leave the chat.
The engineering reality: two platforms, one brain
Here's the part that's easy to underestimate. "Slack and Teams" sounds like one feature. It's two very different platforms with two very different models.
Slack gives you slash commands, Block Kit for interactive messages, and a fairly clean events API. Microsoft Teams gives you the Bot Framework, Adaptive Cards, and a different auth and installation story entirely. The mental model, the message formats, the way a user is identified, the way an app is distributed — all different.
The trap is to build the feature twice. We didn't want two codebases drifting apart, one always a few features behind the other.
So the rule we landed on: the platform layer is thin, the logic is shared. Clocking in, approving leave, calculating overtime — that's one piece of code that doesn't know or care whether the request came from Slack or Teams. Each platform has a thin adapter that translates its own message format in and out. When we add a feature, we add it once, and both platforms get it. When we fix a bug in the shared logic, both are fixed.
It's the same principle as separating your domain logic from your transport in any backend, just applied to two chat platforms instead of, say, REST and GraphQL. Unglamorous, and the thing that kept us sane.
Adoption is a feature, not a marketing problem
The lesson that surprised me most: where software lives changes whether it gets used, more than how good the software is.
A well-designed HR tool that requires a new login gets opened by the one person whose job it is. A mediocre one that lives in Slack gets used by the whole team on day one, because using it is just... typing a message. The bar to action is almost zero.
We saw this with our own early customers. Teams that had abandoned previous tools adopted Tickin the same day they installed it — not because we'd out-designed anyone, but because there was nothing new to learn. The interface was the chat app they'd been using for years.
If you're building internal tools, or any software a team has to adopt, I'd genuinely ask the question before you design a single screen: does this need to be a destination people go to, or can it live where they already are? A surprising amount of software is a notification and a form. Those don't need a new home.
One thing we won't do in chat
For balance: chat isn't the right home for everything. Dense tables, payroll runs across fifty people, configuration — those belong on a real screen, and we didn't force them into a message just to be pure about it. The goal was never "everything in chat." It was "the things people do every day in chat, and nothing that makes those things worse."
Knowing where that line is turned out to be most of the design work.
We're building this at Tickin — HR, attendance and payroll that runs inside Slack and Microsoft Teams, free for up to 10 people. If you've built something that lives inside a chat platform, I'd love to hear how you handled the two-platform problem — it's still the thing I think about most.
