Start Small: How to Choose Your First AI Task in Restoration

So, you're a restoration contractor and you're considering using AI in the business. Or maybe you've already started using AI, but so far it's just

asking a few questions in a chat window. Those are great first steps, but just like in your business, it helps to start with a clearly defined issue, a concrete goal, and a process to get to a defined solution. AI is easy to try in a chat window, but making it truly useful takes relevant job context, one clearly defined task, known boundaries, and a person who owns the next step.

Rather than starting with “What can AI automate?” ask this instead: “What is one check our team repeats, and what would a reliable result look like?” A broad goal like “manage dispatch” is hard to test. A specific task, such as “find active drying jobs with a room missing a required reading and show the source” is easier to define and review.

With that in mind, here's an outline for contractors to start out the right way with AI.

Start with a task your team already repeats

Look for a task that happens regularly, uses records your team can access, and produces a result that you can verify. For a first test, it helps if someone can catch an error before it affects a customer, payment, or job record. Depending on the records available and your shop’s rules, here are some suggestions:

1. Flagging active drying jobs with missing moisture readings
2. Comparing equipment days in field records with the days billed
3. Finding open jobs without a usable dispatch task
4. Identifying carrier-committed claims that may need an invoicing step

Define the task before connecting tools

Write down what the AI should do in plain language:

1. Trigger: When should the check happen?
2. Source records: Which systems and information should it use?
3. Rule: What qualifies as an issue?
4. Output: Should it return a list, a flag, a summary, or a draft?
5. Owner: Who reviews the result and takes the next step?
6. Stop condition: What should happen if information is missing or conflicts?

For example, a first version of a drying-job check might be:

Each morning, review active drying jobs for rooms where equipment is recorded as running but no same-day moisture reading appears in the connected records. List the job, room, date, and source records. If information is missing or conflicting, flag it for supervisor review. Don't create or change records.

The above example should to be tailored to your shop’s records and rules. You need to define what counts as an active job, whether a reading is required for each room, and what qualifies as a valid reading. The last sentence of those instructions is crucial to make sure AI doesn't fill in facts that were never recorded.

Begin with review, not changes

For an initial test, ask AI to find, compare, summarize, or flag information. Have it show the source behind each result so a person can check it and keep record changes and external messages out of the first test.

Make sure the person doing the checking is set up properly in the app to be able to perform what you're asking them to do. In Ruby, access is scoped by organization, workspace, and location. A user seat alone does not grant access to connected data. Connections default to read-only, and write access and per-write approval are separate admin settings. Making sure a user's settings align with what you want them to do sets them up for success rather than confusion or frustration out of the gate.

Make sure you're initially doing evaluations and not running tasks. Ruby Playbook evaluations capture results rather than executing integration writes. Publishing a Playbook requires a ready evaluation and human approval to make sure humans are in the loop from the outset. These controls help keep the test separate from changes to connected systems.

Data handling matters, too. Always check a vendor's privacy policy to see how information is being handled and retained. For example, Ruby’s Privacy Policy explains that prompts may include messages and relevant portions of connected integration data and that AI providers may retain prompts for a limited period under their own policies.

Test the result beside the way your team works today

A polished answer is not proof that a task is ready to use. Test it alongside your current check, and have a person compare the result with the source records.

Use mock or otherwise approved test records, and include ordinary examples as well as cases where information is missing, inconsistent, or unclear. Including the examples with missing or incorrect information will help show whether AI is correctly flagging uncertainty or is giving an answer the records don't support. You should also decide how you'll measure the success of the output. Useful questions include:

1. Did it flag the right records?
2. Did it miss anything important?
3. Did it raise alerts that did not need action?
4. Did it point to the correct source information?
5. How much time did a person spend reviewing or correcting the results?

There's no single 'pass' mark for every task. Choose criteria that fit the task and its risk before deciding whether the result is useful enough to build on.

Make uncertainty part of the check

A useful AI task should have a clear way to handle exceptions. When information is missing or sources disagree, the output should clearly say what it couldn't determine and route the item to the right person. Again, it should not invent a reading, explanation, or next step, and keeping an eye out for this in the initial tests help prevent such occurrences later.

Keep track of recurring exceptions. They may show that the rule needs clarification, the records need improvement, or a particular case should stay with a person.

If you later consider adding a record change or another action, define exactly what the AI is allowed to do, who approves it, and what conditions should stop it for review. Expand one step at a time, based on what the test shows.

SUMMARY

What makes a good first AI task?

Choose a recurring task with accessible source records, a clear rule, and a result a person can verify. Start with a narrow check rather than a broad goal.

Should AI change records or send messages right away?

Not necessarily. Start with a review, flag, or draft. If you later add actions, define the permitted changes, approval requirements, and conditions that should stop the task for human review.

What should AI do when information is incomplete?

It should identify what is missing or conflicting and route the item for review. It should not fill in undocumented facts.

Put Ruby to work

So - ready to give it a go? A lot of things in this outline may seem intimidating, but a lot of that's because of the new terminology and the initial learning curve. In the end, it's easier than you think. Choose one recurring check. Write down its trigger, source records, rule, expected output, owner, and stop condition. Then test it with a person reviewing the result before expanding its permissions or scope.