The user experience of operating and changing a company

An internal system needs two user experiences: one for running the operation now, and one for changing how it will run next.

Most internal software concentrates on the first experience. A salesperson gets a pipeline. A support lead gets a queue. Finance gets an approval screen. The user can see work, change its current state, and move on.

The experience for changing the organisation is usually much worse. A leader explains a new rule in a meeting. Somebody updates a process document. An administrator searches through settings. A request disappears into an engineering backlog or a vendor ticket. The company has a user interface for doing the work, but no designed way to change how the work is done.

An AI-native operating system needs both.

The operations experience is synchronous

The operations experience begins with something happening now: a lead needs an owner, a delivery is late, a refund needs approval, or an invoice doesn't match its purchase order.

The interface should make the current situation obvious. It brings together the record, the evidence, the permitted actions, and the person accountable for the next step. When the user acts, the system confirms what changed and shows the consequence. Nobody should need to reconstruct the case from a CRM tab, an email chain, and a spreadsheet.

This experience optimises for attention and action. It answers four questions quickly:

• What needs attention now?
• What evidence explains it?
• What can I do?
• Who owns what happens next?

The user works inside the rules the organisation has already chosen. The system's job is to make those rules usable during live work.

The organisational-change experience is asynchronous

The organisational-change experience begins when somebody decides that the current rules are no longer good enough. Finance lowers an approval threshold. Revenue changes how leads from a new region are assigned. Operations adds an escalation when a delivery misses two checkpoints. Leadership gives an agent permission to resolve one class of support request without human approval.

These changes don't belong in the live queue. They affect future cases, often across several roles and systems. The experience has to help the organisation move from intent to a safe change in software.

It should answer a different set of questions:

• What behaviour are we changing, and why?
• Which workflows, interfaces, data, and people will it affect?
• What will happen in real examples before and after the change?
• Who has the authority to approve it?
• How will we know it worked, and how do we reverse it if it didn't?

This experience optimises for confidence. Speed still matters, but the user needs to understand the effect before the new rule reaches the operation.

Code is the result, not the business interface

Every accepted asynchronous rule should end up in code. The approval logic, permissions, agent instructions, tests, interface changes, and audit record need one durable implementation.

The person requesting the change shouldn't have to work in Git. Their experience can begin in plain language: “For new suppliers, lower the invoice approval threshold from 20,000 to 10,000. Keep the current threshold for approved suppliers.”

From there, the system and the software facilities team should produce a concrete change proposal. It should show which rule will change, the code and screens affected, and how recent invoices would have moved under the new policy. Finance can see who would receive the additional approvals. The system owner can review the tests. A named approver can accept the release.

Once deployed, the same change remains visible: who requested it, who approved it, when it shipped, what happened afterwards, and how to roll it back.

Chat is useful for expressing intent. It is insufficient as the record of organisational change. The durable record is the reviewed code, joined to the business reason, evidence, approval, release, and measured effect.

Change should feel proportional to risk

Changing a label on an internal screen shouldn't require the same ceremony as changing who can release a payment. The organisational-change experience must scale with consequence.

A low-risk change can move from request to preview to release quickly. A rule that moves money, exposes customer data, or expands an agent's permissions needs stronger evidence, a named owner, and a staged release. The system should make that distinction visible rather than hiding every change behind the same ticket status.

This is where agents help without taking authority away from people. An agent can inspect the codebase, trace dependencies, draft the change, replay historical cases, and prepare the release. The responsible human decides whether the organisation should work that way.

The facilities relationship needs its own interface

Our approach involves staying responsible for the software as the operation changes. That relationship also needs a designed experience.

A customer shouldn't have to send a WhatsApp message and then wait without knowing whether a change is understood, being built, under review, or already live. The request, interpretation, proposal, evidence, approval, and release should be visible in the client's internal system. The operating knowledge stays attached to the change instead of disappearing into agency email threads.

This makes responsiveness more than a promise. The customer can see the facilities team working on the organisation's software, participate at the moments that require judgment, and retain the complete history after handover.

How this guides Aiwah

We design both experiences as parts of one operating system:

• Live operations happen through focused interfaces built around state, evidence, action, and ownership.
• Organisational change begins with the business intent, in the language of the people responsible for the operation.
• Every accepted recurring rule becomes reviewed, tested, company-owned code.
• The customer sees the proposed effect on real cases before approving a consequential change.
• Approval and release controls grow with the risk of the change.
• Every release keeps its reason, owner, evidence, measured effect, and rollback path.

The operations experience helps people run the company under today's rules. The organisational-change experience gives them a safe way to write tomorrow's rules. A company needs both before software can become part of how it evolves.