Case Study: Shift-Tracking Bot and Website for Profline Group

This is our longest case study, and the only one where the order did not end at handover. Profline Group, a Ukrainian staffing company, commissioned a Telegram bot for shift tracking. Months later we were effectively their engineering function: backend changes the same day, incident write-ups against live data, a marketing site in four languages. Below: how a one-off job became a standing role, what broke along the way, and where we told the client no.

Three stages, not three orders

Profline supplies staff to logistics sites — depots and terminals in Kyiv, Odesa, Lviv, Brovary, Vinnytsia, Zhytomyr, Lutsk, Rivne, Ternopil and Chernivtsi. People take shifts, collect a badge that gets them onto the site, work their hours and get paid. Before the bot, this lived in chat threads, voice notes and spreadsheets.

The initial order was one thing: a bot to track people, shifts and money. It went into service in spring 2026. Then the company started opening locations quickly — and a system running real shifts every day is never simply "delivered". Hence the second stage: a technical retainer, where we fix bugs and change backend behaviour on request rather than on a release schedule. The third stage was the marketing site, shipped over the summer.

What the bot does

A worker requests a shift inside the chat: location, date, documents where required. It reaches an administrator as a card showing how many shifts this person has already worked — so regulars can be prioritised. The administrator approves, a badge is issued on site, the worker taps "I am here", and the shift closes with an hours count.

• Badge pool — who took a pass, when it came back, which are free. A named badge returns to the pool automatically after five days of inactivity.
• Excel timesheets matching the client’s existing template: a single day, a range or "the last 7 days", plus a combined view across all locations.
• Reminders and nudges — an hour before the shift, with "I will be there" / "I am not coming"; a separate job notices when a shift has started but nobody pressed start.
• Referral reporting — who brought how many people in, and how many actually turned up.
• A request queue split across three topics: active, badges issued, archive. Previously all of it sat in one stream.

We covered the general approach separately, in the piece on Telegram bots for business and the one on business process automation.

The conversation where we said no

In June the client arrived with a big idea: their own CRM. Every messenger in one window, inbound from job boards, telephony with the candidate card on an incoming call, internal video calls, mirroring of working Viber groups, Telegram group management without leaving the system, timesheets, a worker portal, analytics per manager. We could have agreed and started writing. Instead we sorted the list into three categories and handed it back marked up.

1. 1

   Green — buildable, the foundation exists

   Telegram inbound, a candidate database with a status funnel, assignment to a manager, cities and locations, scheduled broadcasts, timesheets, a worker portal, analytics, payouts. Much of this already lived in the bot.

2. 2

   Amber — possible, but through third parties

   Telephony is not a direct mobile-operator integration but Binotel or Ringostat: they expose the APIs behind click-to-call, recordings, call history and the candidate card on an incoming call.

3. 3

   Red — no official route exists

   The Viber Bot API cannot read group chats the bot is not party to, so mirroring a working group has no legitimate route. Job boards expose candidate correspondence through partner or closed APIs, and scraping breaks their terms. Managing Telegram groups "as a human" needs MTProto — against Telegram’s rules, and it risks the account.

Along with an estimate said out loud: done properly for this company, this is a system on the scale of a small contact centre — a specification of thirty to fifty pages and three to six months of a team’s work. Not one developer on a retainer.

Parts of the green list went into the bot over time. The large CRM was never started. For what integration looks like when done properly, see our piece on CRM integration.

When code cannot fix the problem

In July a complaint came in: at one depot people were taking shifts but not appearing on the timesheet. The easy move was to treat it as a tracking bug. We went into the data instead.

Across every location but one, forty-four real badges were in circulation. In a single day they produced a hundred issuances — each badge turning over roughly two and a half times. Nine went to several people in succession; one went to four. Then something surfaced that could not physically be true: the same badge had been at two different depots in one day — one at 06:55, another at 09:55, back at the first that evening.

The explanation was not a software one. When a worker registers a badge at the client’s terminal, it stays registered to them. The bot knows nothing about that terminal, so it hands the same pass to the next person, who finds it already taken and leaves. With five free badges against fifteen people wanting one, this happened at scale.

This is the most awkward kind of answer to give: the client asked for a software fix and got a conclusion about their stockroom. But the alternative is logic that neatly hides the shortage while people still travel to a shift for a badge that does not exist.

The error that was lying

Two weeks later, another complaint from the same depot: the bot was reporting "no badges available" when there obviously were some. This time it really was lying — but not about the count.

The system supports pools: a badge can be pinned to a location so it stops travelling. The logic was strict — the moment even one badge is pinned to a location, that location stops seeing the global pool at all. Four locations turned out to have a pool of exactly one badge each. Enough for the first worker to take it and lock the location completely, with forty-six free passes sitting in the global pool next door.

An administrator had been pressing "location pool" without knowing the button does not add a badge to a location so much as cut that location off from everything else. We dissolved the four accidental mini-pools, left the deliberate ones untouched, and recorded every changed badge so a rollback would take a minute. It was the second occurrence in a month, so we described the behaviour explicitly rather than reporting "fixed".

Payment tracking with no new interface

Payouts were handled in a working chat: someone posts the payment details, someone pays, and by the end of the week nobody remembers what was settled. The obvious move is an admin panel section. We did the opposite and left the process where it lived.

1. 1

   A templated message

   Payment details are posted in the chat in free form, with one mandatory element — a line stating the amount.

2. 2

   A reaction instead of a button

   Whoever pays adds any reaction. The bot records who, how much and when, then replies with a marker meaning "logged".

3. 3

   Undo by removing the reaction

   Made a mistake? Remove your reaction and the record is deleted. No confirmation dialogs, no correction procedure.

4. 4

   One command for the report

   Totals for today, the week or any period — as text, an Excel file and a spreadsheet at once, in the format accounting already uses.

The win here is behavioural rather than technical: nobody opens a new system or learns a new interface. People do what they were already doing, and the bookkeeping appears by itself. We wrote about this approach separately, in automated reports and alerts.

One payment feature went the other way. The bot used to calculate the amount owed and show it to the worker at the end of a shift — obvious transparency, in theory. In practice people compared that figure with what arrived after the hours were reconciled, and came to argue. The client asked for it to be removed, and we removed it: this is exactly where the client understands better than the developer how a number behaves in a real conversation.

The website, with Urdu as the fourth language

The third stage was the marketing site: Next.js with server components, Payload CMS, PostgreSQL, deployment through Coolify behind Cloudflare, media in object storage, bot protection on forms. The vacancy board is faceted and carries JobPosting structured data so listings can reach Google Jobs. Search sits behind an interface — it runs on PostgreSQL today, and switching to Meilisearch changes one environment variable without touching the UI.

The most interesting decision was a product one: four locales — Ukrainian, English, Hindi and Urdu. Profline brings in staff from India and Pakistan, and the hub for foreign workers is built around WhatsApp rather than a contact form, because that is where this audience replies. Urdu is written right to left, so the layout had to mirror. For how this works in general, see our guide to multilingual websites.

Requirements arrived as voice notes rather than documents: kill the animation that enlarges a block then hides the menu; fix the vacancy card where a long title overflows onto the background; add gender and age to the application form; structure the site for every city, not Kyiv alone. That is a normal way to work with a client who spends their day in operations rather than in mockups.

What the client said

Project status

The bot runs daily across every location the company operates. The website launched in the summer of 2026. The technical retainer continues: work arrives as it comes up, from small changes to incident analysis against live data.

This case study deliberately contains no conversion figures for the site. It launched recently, and publishing a first-week reading as a result would be presenting noise as a trend. When the data exists, we will add it here.

Frequently asked questions about this project

In short

• One Telegram bot for shift tracking grew into three stages: the bot, an ongoing technical retainer, and a marketing website.
• Asked for a large in-house CRM, we returned the list in three categories and named what is officially impossible: mirroring third-party Viber groups, reading candidate correspondence from job boards.
• A shift-tracking complaint turned out to be a shortage of physical passes: forty-four badges covering a hundred issuances a day, which code cannot fix.
• The "no badges available" error lied about scope, not count: pinning one badge silently cut a location off from the global pool.
• Payout tracking runs on message reactions in the chat people already used — no new interface, no staff training.
• The salary calculation was removed on request: the figure provoked arguments instead of delivering transparency.
• The site launched in four languages including right-to-left Urdu; there are no conversion figures yet, and we are not inventing any.