Building an AI employee changes the questions a management team needs to ask. Alongside what the technology can do, there is the practical question of how it should work with the organisation.
Our experience developing DeeJay at UBI Business School brought that question into everyday operations. What may the assistant read? Which task is it preparing? Who reviews the result? How does the team correct a recurring mistake?
The answers form an operating model. They determine whether an AI assistant becomes a dependable part of the workflow and whether people can use it with confidence.
Define the job and the handoff
A request to help with finance can mean several different things: find information, prepare an analysis, draft a reminder, issue an invoice or send a message. Those actions carry different consequences.
In the UBI instalment workflow, we developed support for worklists and draft communications while keeping invoice creation with the responsible colleague. Reviewing the real cases showed why a simple copying rule was insufficient: arrangements differed and records needed interpretation.
A useful implementation makes that handoff explicit. The person reviewing a draft should know what was prepared, what evidence supports it and what still needs a decision.
Turn organisational knowledge into reliable rules
An experienced colleague knows that a field name can be misleading or that two records may describe the same person. An AI system needs a way to handle those details consistently.
At UBI, this meant working through the definitions behind intake reports, financial worklists and correspondence searches. The implementation needed to account for how the source system stored information and how staff understood it.
For repeatable calculations, we used defined reporting logic. For ambiguous matches, the assistant needed to surface the uncertainty. These are operating choices that directly affect the quality of an answer.
Treat feedback as implementation work
We built a review loop to examine prior interactions, identify material errors and capture lessons. That created a way to learn from actual use rather than relying only on a demonstration prepared in advance.
One lesson was that recording a correction is sometimes insufficient. A recurring problem can come from a contradictory instruction, an outdated description of a capability or a missing tool. The lasting improvement comes from finding the cause and changing the relevant part of the system.
A review process therefore needs ownership. Someone must decide which issues matter, check the proposed correction and verify that the change addresses the problem. The feedback loop is part of running the service.
Build the investment case around adoption
A company can have an impressive demonstration and still struggle to obtain business value. The working solution has to fit the team’s tools, responsibilities and tolerance for error.
The UBI work gave us a practical lens for that investment case: which repeated tasks can be made easier, how the output reaches the colleague, what remains under human review and how the improvement will be measured.
These lessons inform IJK’s AI implementation consulting arm. We help companies assess opportunities, design the workflow, build and test a solution, and support adoption. Our cross-border investment perspective keeps the work connected to the wider business: stronger operating capacity, better customer service and a credible path to lasting value.