Paismo AI Copilot, turning HR data into things worth acting on

The principle: a flag is only useful if it ends in an action

A list of alerts is easy to build and easy to ignore. I designed every part of the Copilot around one chain: notice, understand, verify, act, give feedback. Anything that did not serve one of those steps was cut.

Decision 1: The insight card as the unit of the product

Each finding is a single card with a deliberate structure: who it is about, a named anomaly (Timesheet Modifications, Late Check-ins, Excessive Overtime, Missed Punches), a one-or-two-sentence explanation, a way to give feedback, and one button that takes the admin to the relevant place (Go to Timesheets, Go to Leave Management).

A few choices inside that structure:

• The key phrase in each explanation is bold. An admin scanning twelve cards can read only the bold text and still understand each one.

• The Copilot speaks in the first person (I detected, I flagged, I noticed). It reads like a colleague handing over a finding, not a system log, which fits an assistant that is meant to be asked questions.

• Every card deep-links into the module where the work happens. The Copilot is a triage layer on top of Paismo's existing tools. It does not try to replace timesheets or leave management, it points the admin to them with the problem already identified.

• The wording is hedged where it should be. Cards say a pattern may require follow-up, may raise concerns about workload, may violate policy. The Copilot describes what it sees and leaves the judgment to the human. For a feature that talks about people, I treated that as a product decision, not a copy detail.

What I chose not to do: build a long alert table with columns and filters, or put analysis charts on each card. That would have made the Copilot a second reporting tool instead of a fast route to the next action.

Decision 2: Organize by how HR already thinks, then give two lenses

The Copilot is split into four tabs: Attendance, Performance, Payroll and Compliance. These mirror how HR teams divide their work and how the rest of the product is organized, so an admin always knows where to look.

Inside each tab there are two views, Department and Employee, each with its own multi-select filter. They answer different questions. A department view surfaces collective patterns such as excessive late arrivals, high leave rejection or overlapping leaves, which usually point to a scheduling or management issue. An employee view surfaces individual anomalies, which call for a conversation or a correction. The two need different responses, so I did not mix them in one feed.

The flow opens on the Attendance tab with the Department view selected by default, so the first thing an admin sees is the pattern rather than a person.

The flow board covers all eight combinations (four tabs by two lenses), the filter dropdowns with an Apply step, and the first-run introduction state, so the whole system is specified rather than just the happy path.

What I chose not to do: one flat feed of everything, which would have mixed systemic issues and individual ones and made both harder to act on.

Decision 3: Make the AI correctable, and make it balanced

Every card carries a thumbs up and thumbs down. It is the lowest-effort way to tell the Copilot whether a finding was useful, and it is also how the product earns trust over time: the admin can see that the system is meant to learn from them. In the demo flow, a card records who marked it, so a team of admins can see what has already been reviewed.

The feed is not only red flags. It includes positive signals too, such as an employee whose attendance has improved or whose attendance has been consistently high. A product that only ever reports problems about people becomes a surveillance tool in the admin's mind, and in the employees' too. Including good news keeps the Copilot closer to an honest assistant than to an auditor.

Decision 4: Honest about freshness, honest about cold start

Freshness. The Copilot page shows when insights were last updated and when the next update is due. It does not pretend to be real-time, so an admin knows exactly how current the findings are and does not wonder why something from this morning is missing.

Cold start. A new account has no baseline, so the Copilot genuinely cannot say anything useful yet. Instead of an empty page, I designed a state titled Your Copilot is learning on the job. It shows a blurred preview of the kind of insights the Copilot will produce, explains that the data will be ready in a set amount of time, and offers an upgrade path to unlock it sooner. It turns a dead end into three things at once: an honest explanation, a preview of the value to come, and a clear option for the admin who wants it now.

What I chose not to do: show an empty state with generic copy, or fill the page with fake findings to look useful.

Decision 5: Easy to find, easy to introduce

Copilot is reachable from a persistent Ask Copilot control in the top bar and from its own entry in the navigation, including the collapsed navigation. A first-run state introduces it before the admin meets the feed, and the home screen greets the user conversationally (What can I help you with today?), which sets the expectation that this is something to ask and work with, not just a page to read.

Result

I will be precise rather than impressive: I did not have access to usage data and there was no formal testing, so I will not claim metrics.

What the work produced:

• A complete experience for an AI feature, not only the feed: entry points, an introduction state, four domain tabs, department and employee lenses with filters, feedback on every insight, and a cold-start state.

• A card pattern that connects every finding to a next step in the existing product.

• A tone and structure for AI findings about people that is hedged, balanced and human-reviewed by design.

• A demonstrated flow for the attendance experience, showing the cards arriving and the feedback interaction in motion.

How I would measure it:

• The share of insights that lead to a click through to a module, which tells us whether findings are actionable.

• The thumbs-up to thumbs-down ratio by anomaly type, a practical proxy for how accurate each kind of finding is.

• Time between an anomaly appearing and an admin acting on it.

• How many admins return to the Copilot each week.

• Conversion from the cold-start state to upgrade.

What I would do differently

The cards currently end in two actions, give feedback and go to the module. They have no resolved, snoozed or assigned state, so an admin cannot tell a handled finding from a new one. That would be my first addition, because a triage tool needs a way to mark things done.

I would also let the admin see the evidence behind a finding, such as the peer baseline or the pattern over time, without leaving the card, so verification is faster and trust grows. And I would test the department-first default and the first-person voice with real admins, since both are reasoned choices I could not validate.

Reflection

Most of the work in an AI feature is not the model. It is the last few feet: whether the output is understandable, whether it is worded responsibly, whether the person knows what to do next, and whether they can tell the system when it is wrong. The Copilot taught me to design the trust and the next action first, and to be honest with users at exactly the moments the AI has nothing to offer.