Jetbro · Technology services

We run our own people operations on it.

People operations

Leave, work from home, attendance, assets and requests for our own team, with the policy applied by the system and every decision on a timeline.

Built on Phlo for Jetbro's own team.

Industry
Technology services
Capability
People operations
Replaced
Announcements in chat and a shared spreadsheet
Team
About 25 people
Modules
Nine

The system

One leave request and its timeline. Nobody decided it inside the response window, so the system rejected it. A Director is looking at it and can still approve it. Rebuilt for this page with invented sample data.

Jetbro builds Phlo, and delivers client systems on it. We are about 25 people. Our own leave, attendance, assets and requests run on a portal we built on Phlo, the same way we build for clients.

How it ran before

Leave was announced in a chat channel or sent by email, with no formal approval step. HR logged it afterwards in a shared spreadsheet that kept no running balance. Attendance was not tracked in any central place. Working from home looked the same as leave in the records, so nobody could count it.

Requests for hardware were made in person or by direct message, with no status the requester could check. Employee documents sat across email and chat. Assets were tracked informally. Each month HR compiled attendance and leave by hand for the accountant.

None of this is unusual for a company of our size. It is the capability every firm owns informally. We wanted the policy applied by a system, and a record of what was decided.

What we built

A self-service portal with nine modules: Employee, Leave, Work From Home, Attendance, Attendance Report, Assets, Requests, Holidays and Notice Period. There are three roles: Team Member, HR and Director. People sign in with Google, and only an address that matches an active employee record, or the portal’s administrator account, is let in.

Notifications go out three ways: a bell in the portal, Slack and email. Every action is stored as an event. Scheduled jobs emit events too, with the system recorded as the actor.

How a leave request moves through it

  1. Apply. The team member picks a leave type and dates. The rules are shown on the page before they apply. The system checks the advance notice, which grows with the length of the leave. Weekends and public holidays are not deducted.
  2. Notify. HR, the Directors and any additional approvers named for that person are all notified at once. The first to act closes the request for the others.
  3. Decide. An approver approves, or rejects with a reason. If nobody decides inside a set share of the time left before the leave starts, the system rejects the request and tells everyone. HR or a Director can still approve it afterwards.
  4. Apply the decision. Approval deducts the balance and tells the team member by bell, Slack and email. A line is posted to the team’s HR channel in Slack.
  5. On the day. Early each leave day, a job marks the person as On Leave, so they get no attendance reminders.

What the first build described

Writing the portal meant describing our own people operations precisely enough for a system to apply them. This is that description: what is tracked, what can happen, and the cases a policy document tends to leave to judgement.

  • The things tracked. The employee record and its documents. The leave request and the leave balance. The work-from-home request. The attendance day, one for each person and date. The monthly attendance report. The asset, physical or digital, and who holds it. The request type, which HR defines, and the request made against it. The holiday. The notice period. The notification.
  • What can happen to leave. It is requested, approved, rejected or cancelled by a person. It is also approved, rejected or cancelled by the system, and the record says which. An approval by rule is a different event from an approval by a Director.
  • What can happen to an attendance day. It is marked by the team member, set to On Leave by the system, recorded as Absent by the system, flagged as unapproved work from home, or edited by HR or a Director.
  • What can happen elsewhere. An asset is created, assigned and returned. A request is submitted, approved, rejected, fulfilled or cancelled, and comments are added to it. A notice period is started. A holiday is added or removed.
  • Exception: sick and emergency leave. These are approved automatically and are exempt from the notice rule.
  • Exception: nobody answers. Silence is modelled. The request is rejected by the system when the response window closes, and a person can still overturn that.
  • Exception: a change of plan. A team member can withdraw a pending request or cancel an approved one. The balance is restored and the attendance entry cleared.
  • Exception: working from home without asking. Marking a day as work from home with no approved request behind it is recorded, and flagged as unapproved.
  • Exception: the forgotten day. People who have not marked attendance are reminded through the working day. Anyone still unmarked in the evening is recorded as Absent by the system. HR or a Director can correct it later, and can record a reason.
  • Exception: a resignation. HR records a notice period. Open leave is cancelled automatically, new requests are restricted, and the person’s assets are flagged for recovery.

Policy, held by the system

Work from home has its own rule. A single day asked for with notice, or a same-day emergency, can be approved automatically by rule, within a monthly limit. Everything else goes for approval, with the same response window as leave.

Request types are defined by HR, who build each type’s form in the portal. An approved request is later marked fulfilled, and it carries a comment thread.

At month end HR downloads the attendance template, completes it and uploads it. HR and Directors see the whole report. Each team member sees only their own row.

The portal holds sensitive employee data, and access to it is restricted by role.

What the record makes possible

Every leave request, work-from-home request and general request has a timeline: who asked, who decided, and when. A corrected attendance day still shows what it was before and who changed it.

The policy is not a document people are asked to remember. It is what the system does with a request, and what it did is on the record.

What the foundation carries forward

We build this portal the way we build for clients, on the same framework, and that is why it appears here. The employee record, the three roles, the approval pattern of several approvers with a response window, and the notification channels are already built.

A further internal system would start from those. It would know who works here and who may approve what, and it would sit on the history the portal has already recorded. Payroll, payslips and expense claims are outside this portal’s scope.

The record

Every step is recorded as an event.

One team member's leave request and the days around it. The automatic rejection on 4 October was not erased when a Director approved the request the next morning. Both are events, and both stay on the timeline. The same holds for the absence that HR later corrected.

The event types are the system's own. The times, figures and names are invented for this page.

How a system of events works

One chain of events, as stored

  1. 1 Oct 10:12Leave requestedLR-2026-0052 · casual, 19 to 21 Oct · advance notice met3 days
  2. 1 Oct 10:12Notification createdHR, the Directors and the additional approver, all at once
  3. 4 Oct 22:34Leave auto rejectedBy the system · nobody decided inside the response window
  4. 5 Oct 09:20Leave approvedA Director approves the auto-rejected request · balance down three days
  5. 5 Oct 09:20Notification createdThe requester is told by bell, Slack and email
  6. 19 Oct 06:00Attendance set on leaveBy the system, on each leave day · no reminders sent
  7. 22 Oct 09:05Attendance markedBack at work, marked after the morning reminderPresent
  8. 23 Oct 19:00Attendance auto absentBy the system · not marked by the evening cut-offAbsent
  9. 26 Oct 11:30Attendance editedCorrected by HR, with a reason · the earlier value stays in the historyPresent

Keep reading

The idea underneath it.

All case studies

Get started

Every process in your operation, on one system.

Tell us how your operation runs today, and we will come back with what it takes to build it: the processes, the scope, and the timeline. Every system is scoped and built with you, so the first conversation is about your operation, not a demo.

coffee@jetbro.inWhatsApp +91 90999 62227