The question was simple. The rule behind it was not.

Teams needed to interpret policies that were connected to one another: how a commission breaks down, how a ranking is determined, how reward points are counted, or which rule applies to a particular situation.

A conventional search box could find a document, but it could not do the useful final step: connect the question to the relevant rules and explain the result in language the team could act on.

• 01Operational knowledge lived as policy, not as direct answers to real questions.
• 02Commission and ranking questions often required context, not a single keyword match.
• 03The same recurring questions consumed attention that should have gone to the work itself.

Build the interface around the question.

I built an internal AI agent that lets a team member ask in natural language, then works across the company’s operational knowledge to return a focused answer.

The important design decision was not simply adding chat. It was shaping the system around the brokerage’s own concepts—commission components, rankings, reward points, and policy—so the conversation stays attached to the operation.

Ask a question. Get the breakdown — and the source rule.

This is how it feels in use: an agent asks the way they'd ask a manager, and the answer comes back as numbers, reasoning, and the policy it came from. Below it, the view management opens every morning.

Illustrative mockups — people, deals and figures are fictional examples, not client data.

One assistant across the rules that drive performance.

The request moved. Its context did not always move with it.

Creating a request was only the first step. The business also needed to know where it was, who was responsible for the next decision, and how requests accumulated across departments.

When the workflow and the reporting layer are separated, people spend time reconstructing the story after the fact. The same record has to serve both purposes from the beginning.

• 01Requests needed a consistent structure across different departments.
• 02Review status and ownership had to remain visible as a request moved.
• 03Department reporting needed to come from the operational record, not a parallel summary.

Make reporting a consequence of doing the work.

I built the payment-request workflow and the department reporting view around the same records. A request enters once, follows its review path, keeps its status, and remains available to the reporting layer.

That shared structure matters more than any individual screen. It gives the business one operational history rather than a workflow in one place and an explanation of it somewhere else.

One request, visible from the first click to the final report.

Staff don't fill in a form and hope. They watch their request move. Managers don't chase updates — they open one dashboard and see every department at once.

Illustrative mockups — suppliers, amounts and departments are fictional examples.

A focused finance operation from request to view.

A record without follow-through is only half a system.

Employee information could be structured, but the actions connected to that information still needed ownership. A dossier might be complete while a related task remained separate, invisible, or difficult to trace.

The problem was not simply storing more fields. It was connecting the stable record of a person with the changing work that surrounds that record.

• 01Employee dossiers needed one consistent internal structure.
• 02Related work needed clear assignment and a visible state.
• 03Teams needed continuity between the record, the task, and the follow-up.

Treat records and actions as parts of the same operation.

I built the people records and task handling as connected parts of one internal system. The dossier provides the durable context; the task layer gives the business a way to act on that context and see the work through.

This creates a foundation the company can extend without splitting the operation into disconnected tools every time a new people process appears.

The dossier and the work, on the same screen.

Open a person and you don't just see their record — you see what's open, what's overdue, and what was just completed. Management gets the same truth at company level.

Illustrative mockups — names, headcount and tasks are fictional examples.

A practical core for people-related operations.

The first release should be fast without being generic.

Starting every engagement from zero wastes time on stable building blocks. Starting from a fixed product creates the opposite problem: the company has to bend its operation around someone else’s assumptions.

The reusable project module sits between those extremes. It provides a working operational core, then changes around the roles, signals, and decision paths of the business adopting it.

• 01Teams need a clear unit of work and a named owner from the beginning.
• 02Visibility must include the people following the work, not only the assignee.
• 03Notifications should reflect meaningful changes instead of producing noise.

Reuse the foundation. Redesign the company-specific layer.

I built the module around the parts that recur across normal company operations: projects contain work, tasks carry ownership, followers retain visibility, and notifications surface change.

From there, the implementation can adapt its terminology, permissions, states, and views to the company. Reuse shortens the path to the first useful release without pretending every operation is identical.

The board the team works from — and the view the boss checks.

Same data, two altitudes. The team lives in the board; management lives in the sync view, where a project turning red is visible before anyone has to report it.

Illustrative mockups — projects, owners and figures are fictional examples.

A coordinated base for work that crosses a team.

HRM often begins with records, then quickly becomes workflow.

An employee profile is useful, but it is rarely the end of the need. Dossiers gather information; tasks create follow-through; permissions define who can see and act; company-specific processes determine what comes next.

A practical starting module has to establish the record model without closing off the workflows that will eventually depend on it.

• 01People information needs a consistent structure from the first release.
• 02Related actions need to stay connected to the record that gives them context.
• 03The system must leave room for company-specific roles and processes.

Establish the durable core, then add only what the operation earns.

I built the HRM module as a reusable base for employee dossiers and connected work. It can be applied to a normal company quickly, then extended as discovery reveals the actual people processes the system needs to support.

The result is not a fixed catalogue of HR features. It is a head start: proven record and workflow foundations ready to be shaped around one company.

From a spreadsheet of names to a people system in week one.

The first release is deliberately small — directory, dossiers, and the follow-ups attached to them — but it already gives leadership a live picture instead of a monthly spreadsheet.

Illustrative mockups — people, teams and figures are fictional examples.

The first layer of a broader people system.