smengo
About the product

A system for teams that work in shifts

At the centre is the schedule: employees down the side, days of the month across the top. Around it — shift execution in Telegram, hours in the timesheet, and open interfaces outward: API, webhooks, calendar.

One loop from hiring to timesheet: hiring → onboarding → schedule → shift → actuals → analytics. Modules hand data to each other, so nothing is typed in twice.

Core
The employees × days-of-month schedule: statuses, presets, coverage per department
Execution
Clock-in and clock-out in Telegram — nobody has to install an app
Records
Timesheet snapshot in whole minutes, planned against actual, period lock
Outward
REST API v1 (9 endpoints), webhooks (4 events), ICS subscription, Poster POS
Languages
English, Ukrainian, Russian — interface, emails and bot
The core

Everything rests on one grid

The month opens as a table: rows are people, columns are days. Shift status and preset go straight into the cell, department coverage is counted against your thresholds. Publishing the month is a separate cut-off action: before it the system runs the labour rules and records who closed the month and when.

Four limits are checked while you place the shift, not afterwards: hours per day, hours per week, minimum rest, consecutive days. The warning shows up in the grid, in the shift editor and at publication; the labour-code preset fills the defaults in.

01
Plan

Shifts are placed, coverage per department meets the thresholds, conflicts are highlighted.

02
Publish

The month is cut off: labour rules checked, the log records who published it and when.

03
Shift

People see their own shifts in the bot and in their phone calendar — no broadcasts in chats. The bot offers open shifts in waves and takes swap requests.

04
Actuals

Arrival and departure are recorded by the time of the tap, not by “I think he made it by nine”.

05
Timesheet

Planned against actual in whole minutes, the period closes with a lock, export to XLSX/CSV.

What is inside

Nine parts working on one schedule

Everything below already runs in the product — no roadmaps, no “coming soon”.

01

The schedule grid

The whole month: shift statuses, presets for recurring patterns, coverage per department with thresholds, publishing as a separate deliberate action.

02

Telegram instead of an app

People clock in and out in the messenger they already have installed. Open shifts arrive there in waves, and swap requests go back the same way.

03

Labour rules

Four limits: hours per day, hours per week, minimum rest, consecutive days. There is a labour-code preset; warnings appear in the grid, in the editor and at publication.

04

Demand forecast and labour budget

The forecast is built from donor days of the same weekday, and shift cost from position rates. You see the number before publishing, not at month end.

05

Schedule generator

A deterministic solver: hard constraints plus coverage shortfall. On top of it, edits in plain language — no formulas to configure.

06

AI assistant in the app

A chat with read tools that run under the permissions of whoever is asking. It explains the draft schedule, sends morning briefings to Telegram and proposes actions — each one confirmed by a human.

07

Knowledge base

Company documents with meaning-based search. The bot answers an employee with an excerpt and shows which document it came from.

08

Hiring and onboarding

Résumé parsing, an onboarding board generated from a template, training with quizzes and completion confirmed in the bot.

09

Timesheets and analytics

A snapshot document in whole minutes, a period lock, export to XLSX/CSV. Next to it: what-if by person, department comparison, detectors for repeated lateness, overtime and coverage gaps, and burnout flags.

Principles

Three decisions you can see in the interface

01

Permissions are checked on read

An integration never receives more than the person who issued the key can see in the interface. The scope is enforced in the app and in the database — at the query level, not in the docs.

02

Copy stays industry-neutral

No “guests” and no “till” in the interface: the same wording reads the same in a restaurant, a warehouse and a clinic. Industry specifics live in the settings, not in button labels.

03

Every number is explained

Next to each metric it says what exactly it counts and what to do about it. If a number cannot be explained in one line, it is not shown.

Openness

Your data is not locked inside

Four channels outward — under keys, signatures and the permissions of whoever issued them.

Public REST API v1
Nine read-only endpoints: organisation, departments, employees, schedule entries, shift presets, status types, check-ins, timesheets, demand signals. Keys are stored hashed, each with its own scopes and rate limit.
Outgoing webhooks
Four events: schedule published, schedule entry changed, check-in recorded, swap decided. Signed requests, retries with backoff, and a test event to verify your endpoint.
Shift calendar (ICS)
Subscribe by link: an employee's shifts land in their own calendar and keep themselves up to date, with no manual export.
Poster POS
Till data becomes a demand signal: the forecast is built on the venue's actual load rather than on gut feel.
Languages and industries

Three languages, two currencies

Interface, emails and bot are translated in full, not in part: an employee and a manager can work in different languages inside the same organisation.

The product grows on requests from the teams running on it

Early access: 14 days of full access, no card required. If something does not fit your shifts, write to us — it goes into one of the next releases.

14 days free · no card required