How to prioritize AI workflows in a portfolio company

01

Write the workflow before you choose the tool

Follow one completed piece of work from its trigger to its final outcome. Identify every handoff, input, decision and exception. Watch the person who does the task. A process map built only from interviews often misses the spreadsheet, copied text or approval that controls the real work.

Describe the problem in operating terms: delayed quotes, repeated data entry, slow reporting, inconsistent record updates. Then ask whether the task needs judgement, language interpretation or generation. A stable calculation or exact routing rule may need ordinary automation. An unclear policy needs a process decision first.

• Trigger: what event starts the work, and how often does it occur?
• Inputs: which systems supply the information, and can the owner lawfully use it for the agreed purpose?
• Output: what does a correct result look like, and who accepts it?
• Exceptions: what happens when information is missing, conflicting or sensitive?
• Ownership: who maintains the process and handles failures after launch?

02

Use a priority matrix with a stop column

Choose a small candidate set and resolve the stop conditions first. Rank the remaining work by expected benefit, effort and uncertainty. Do not average a severe control gap into an attractive score. A pilot should answer the most important unknown at a cost the business accepts.

03

Calculate capacity with review time included

Start with observed task volume and staff handling time, then subtract the proposed workflow time and expected review effort. Keep implementation, training, monitoring and maintenance outside this narrow calculation and assess them separately. Time released becomes capacity only when the team can use it for other work.

Illustrative case: 400 tasks a month take eight minutes each. A proposed process takes three minutes per task, and a quarter of tasks need two extra minutes of review. That releases 30 hours per month before setup and ongoing support. Replace every assumption with observations from the pilot.

Use staff handling time, not AI runtime or elapsed waiting time. Extra review must exclude handling already counted. The calculator below uses this illustrative case. Its output is a planning estimate, not savings, profit or a forecast.

04

Agree the pilot evidence before the build

Create a test set from work the team can use, with ordinary cases and difficult exceptions. Have the process owner define acceptable outputs without seeing the model's answer first. Measure errors, review time, completion time and recovery effort alongside task volume.

NIST's AI Risk Management Framework groups risk work into Govern, Map, Measure and Manage. Its guidance calls for testing before deployment and during operation. Apply those ideas to the specific task, with recorded owners and decisions rather than a generic policy document.

• Record a baseline from the current process and a separate set of evaluation cases.
• Agree accuracy, exception handling, review and timing criteria with the internal owner.
• Keep external messages and material actions behind the agreed approval step.
• Test missing inputs, conflicting records and tool failure, including manual recovery.
• Run the completion test with the internal owner operating the system.

05

End discovery with a decision, not a tool list

The approval record should identify the problem, evidence, chosen workflow, alternatives, dependencies, cost assumptions and acceptance test. Include the decision to stop when the case is weak. If the pilot passes, agree the production scope and monitoring before expanding.

Tenth's Direct AI Transformation path starts with focused discovery and separately approved builds. A priority matrix helps make that discovery concrete; it does not commit the company to a particular product or implementation.