← What we do

AI at work / In development

Make the work better.
Then check the bill.

AI may help read documents, organize information and prepare a first draft. The useful question is whether it improves the work after someone has checked it.

We are developing this approach. The examples below describe ideas to test, not finished products or client results.

How we would test it

How we would start

One task.
A fair comparison.

Choose a specific piece of work and agree on what a useful result would look like. Compare the new method with the way the task is done today.

01 / UNDERSTAND

What is taking
too much time?

Follow the task from the first document to the final decision. Find out where people repeat work, wait for information or correct mistakes. Check whether the source material is reliable enough to use.

  • Which documents and people does the task depend on?
  • How long does it take, and where do errors occur?
  • What would need to improve to make a change worthwhile?

What we would write downThe task, its current cost and the improvement we would test for.

02 / TEST

Try it on
a small scale.

Use a limited set of documents and give one person responsibility for checking the output. Decide which information the tool can use, what it may do and when it must stop for a person to review it.

  • Agree on what a correct answer looks like.
  • Test ordinary cases and likely mistakes.
  • Keep a way to do the work if the tool fails.

What we would write downThe test, who checks it and the conditions for stopping.

03 / COMPARE

Is the result
worth the cost?

Compare accuracy, time and cost with the original method. Include setup, software, checking, corrections and upkeep. If the result falls short, change the test or stop.

  • Did the work become more accurate or useful?
  • How much time was saved after checking and corrections?
  • Do the benefits justify the full cost?

What we would write downWhat worked, what failed and whether to continue.

Ideas we are exploring

Start with the documents
people already use.

These examples show where we would begin testing. They do not describe software that is ready to buy.

In development

Reviewing a deal

A possible starting point is to gather facts from deal documents, show where each fact came from and flag gaps for review. That could help someone prepare an initial analysis or a committee paper.

A person would still need to check the sources, make the assumptions and decide whether the investment makes sense.

In development

Checking property performance

Another task to test is comparing property reports, finding figures that do not agree and listing questions for the asset manager. The test would need to show whether it catches useful issues without creating too many false alarms.

Every flagged figure would need a source that the reviewer can check.

Before the test

Get the records in order.

Find the right documents, identify the current versions and agree on what the numbers mean. Decide who may see each file. These steps matter even if no AI tool is used.

Questions worth asking

Who checks the work?

Someone must be responsible for the answer. The test should make it possible to trace important facts to their sources and should require a person’s approval before the tool takes actions beyond its agreed limits.

Testing our own work would be an internal check. An independent review would require a separate reviewer.

What does it really cost?

Count software, setup, staff time, checking, corrections and upkeep. Compare those costs with a measurable improvement in the work. A draft produced in seconds may still need a long review.

Start with a task

What keeps taking
more time than it should?

Tell us what the task involves, who does it and where it gets stuck. We can start by discussing whether it is worth testing a different way.

Tell us about the task

This opens your email application. Please describe the task without sending confidential documents.