How this works

Use this when employees have many small automation ideas but the organization lacks a reliable way to find existing solutions or connect requests with capable builders. AI organizes the intake, proposes reuse and prepares a bounded implementation brief.

The board should reward resolved work, not a growing pile of ideas. Each request needs a real process owner, concrete input and desired output. Reuse suggestions remain candidates until someone verifies that the existing tool meets the request’s data, permissions and operating constraints.

Before you start

Prepare the inputs

request

Required

Structured form or employee description

Capture recurring trigger, current steps, frequency, input and expected deliverable.

solution_inventory

Required

Tool and workflow records

Distinguish active, experimental and retired solutions; record access requirements.

builder_directory

Optional / conditional

Voluntary capability and capacity records

Do not infer skill, availability or performance from private employee data.

Implementation, step by step

1. 01

   Clarify the process problem

   • Extract the recurring trigger, work performed, input sources and desired output. Ask only for gaps that prevent a meaningful match.
   • Separate a named tool request from the underlying business need. Record baseline measurements as unknown when they have not been observed.

   Checkpoint: The request describes a repeatable task with an accountable process owner.

2. 02

   Find duplicates and reuse

   • Search the approved inventory for matching triggers, transformations and outputs. Compare constraints, not just similar titles.
   • Propose merging genuine duplicates while retaining each requester’s context. Show why an existing automation fits and which requirements it does not cover.

   Checkpoint: The board distinguishes reuse candidates from genuinely new build needs.

3. 03

   Assess readiness

   • Check input availability, data sensitivity, approval requirements and expected action scope. Mark requests that lack a usable sample or process owner as incomplete.
   • Identify a small pilot outcome and explicit exclusions. Do not promise autonomous execution merely because a tool can technically access the system.

   Checkpoint: Each request has a readiness state and a bounded next action.

4. 04

   Match a responsible builder

   • Use declared skills, tool access and stated capacity to suggest builders or a support team. Explain the capability match without ranking employee worth.
   • Require the builder and process owner to accept the assignment. If nobody has capacity, keep the request visible rather than fabricating ownership or a delivery date.

   Checkpoint: Assignments reflect real acceptance and a clear handoff.

5. 05

   Close the loop with evidence

   • Prepare the pilot brief, acceptance checks and review date. For reuse, verify the existing tool on an authorized sample before marking the request resolved.
   • Record what was built or reused, who maintains it and any rollback instructions. Update the inventory after acceptance so future requests can find the result.

   Checkpoint: The board tracks submitted, matched, piloting and accepted outcomes separately.

Decisions along the way

What you will produce

Check the result

• Check every accepted request has a real process owner and maintainer.
• Verify reuse matches against actual inputs and permissions.
• Keep estimated benefits separate from measured pilot results.

When something goes wrong

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Run a small pilot

Keep the scope clear

• AI proposes matches; employees and process owners accept responsibilities.
• Do not fabricate benefit estimates, assign work silently or deploy a solution merely to close a board item.