Now Start an internal tool with the records, relationships and decisions it must support. Then build a view that makes the real work easier to inspect.
A pipeline board can look finished while answering the wrong question. Its cards have company names, deal values and attractive status labels. But if the system stores only the current stage, the board cannot tell you how long a deal has been stuck there. Changing the colour of the cards will not recover the missing history.
That is a useful starting point for internal tools built with AI assistants: define the records and decisions first, then design the view. The interface should reveal what the business knows and make the next action easier to take.
Begin with the question the tool must answer #
Take a small CRM. The team wants to know which open opportunities need attention today. A list of companies and deal values is insufficient. It needs an owner, a current stage, the history behind that stage, and a next action with an explicit state.
Write the question before drawing the board:
Show open deals with an overdue next action. For each one, show who owns it, when the stage last changed, and the evidence behind the next step.
Every part of that sentence implies a record or a definition. What counts as open? Which date makes an action overdue? Does completing an action create a new one, or can a deal legitimately have none? Those choices belong to the team's process and should be written down.
Model the smallest useful set of records #
The first version does not need a large schema. It needs relationships that preserve the meaning of the work.
| Record | Minimum useful information | What it enables |
|---|---|---|
| Company | Stable identity and name | Connect activity without relying on spelling |
| Deal | Company, owner, stage and status | Identify the current opportunity |
| Stage change | Deal, previous stage, new stage and timestamp | Calculate time in the current stage |
| Next action | Deal, owner, due date and state | Separate pending work from completed work |
| Interaction | Date, participants and source reference | Explain why the proposed action exists |
A spreadsheet can be useful for exploring this model. Stable IDs and explicit columns make it easier to move into a system with stronger validation and access controls later. Avoid encoding several meanings into one free-text cell simply because the first dashboard only needs to display it.
For imported records, preserve what is unknown. If an import gives you the current stage but no stage history, mark the stage-entry date as unknown. Setting it to the import date would make every deal appear newly advanced. A truthful blank is more useful than a precise but invented age.
Let the first view test the model #
Once those records are available through an authorized read interface, an assistant can help prepare a board, table or summary. The first review should use representative records and check the answer against the underlying data.
Does a completed action still appear overdue? Does a deal without an owner disappear from the list? Are deals with unknown stage dates distinguishable from genuinely recent changes? Does the total include the same population as the rows?
These questions expose defects that a polished mockup can conceal. They also make the interface discussion concrete. A separate lane for missing owners may matter more than the shape of a deal card.
Keep the source records authoritative. A generated summary or exported board should show its scope and freshness, especially if someone will act on it later. Rebuilding the view should not create a competing copy of the company's operating data.
Separate viewing from changing #
A tool that displays overdue actions has a different responsibility from one that changes deal stages, sends reminders or posts a journal. Reading a record should not grant permission to modify it.
Define supported actions with clear inputs and outcomes. Validate the caller's authority and the record's current state when the action runs. Preserve who changed it, what changed and why. When review is required, the reviewed proposal must correspond to the action that executes.
This matters particularly in finance. A chart can be regenerated; a posted accounting entry has lasting consequences. An assistant's persuasive explanation cannot replace the controls on the operation itself.
Keep business policy editable #
The data model can support a due date without deciding that every follow-up must happen within two days. It can record an approval decision without making one manager's threshold universal.
Separate the shared mechanics from local choices. Record identity, access checks and a reliable change history belong in the system's foundations. Follow-up timing, escalation preferences and review criteria should be explicit configuration or instructions with a named scope and owner.
That separation lets a team change its operating procedure without quietly changing what an existing record means. It also lets different assistants work with the same data while respecting the same controls.
Design the interface where it matters #
Data first still leaves substantial interface work. Repeated tasks need predictable navigation. Review screens need to make evidence and consequences visible. Accessibility, error recovery and sensitive-data handling deserve deliberate design.
The sequence is the point: begin with the business question, model the evidence needed to answer it, and test the view against that evidence. Then invest in the interface around the work people actually repeat.
For a lightweight internal reporting tool, a generated view may be enough. For a frequent approval workflow, a durable designed interface may be the better choice. Both should use the same authoritative records and supported actions.
Applying the approach to finance #
Arfiti's approach is to provide shared accounting infrastructure that teams and compatible assistants can use through supported tools. Its built-in agents are optional workflows over that foundation. The dashboard remains useful for setup, inspection and review.
A finance team might begin with a concrete question: which supplier bills need attention before payment? The answer needs bill balances, due dates, vendor details and the relevant review state. A useful view makes those facts easy to inspect; an authorized payment workflow handles the subsequent action.
See the shared financial foundation and approval workflows for the boundaries. To discuss a particular internal finance workflow, request access and describe the decision your team needs to make.