Automation Intake Triage (Onboarding)

Automation Intake Triage (Onboarding)

1. 01

   Log every candidate workflow the client names, with the person who performs it today and the hours per week it consumes

   Capture the request in the client's own words before anyone reframes it as an automation opportunity. Volume and frequency numbers decide priority later.

2. 02

   Classify each workflow as rule-based, judgment-based, or mixed

   Rule-based work with stable inputs is the only safe starting scope. Mixed workflows get split so the deterministic half ships first.

3. 03

   Confirm the systems of record and whether each exposes an API, a stable UI, or neither

   A workflow spanning three portals with no API pushes the engagement toward UI-level bots, which changes both build time and breakage risk.

4. 04

   Score each candidate on volume, error cost, and stability of the underlying interface

   High-volume, low-error-cost, stable-interface work returns the fastest. A process that changes screens monthly will not hold a retainer.

5. 05

   Map every human approval point that must survive automation

   Budget moves, customer-facing messages, and regulated filings need a named reviewer. Removing the gate is a scope decision, not a build detail.

6. 06

   Set a baseline metric for the current process before any bot runs

   Record cycle time, exception rate, and cost per transaction. Without a baseline the client cannot see the return and renewal conversations get subjective.

7. 07

   Write the out-of-scope list and get it signed alongside the statement of work

   Name the adjacent processes the client will inevitably ask for mid-build. Pricing those later is easier than defending an unpriced expansion.

8. 08

   Pick one platform tier for the account and commit to it for the engagement

   Enterprise suites such as Automation Anywhere suit compliance-heavy clients; prompt-driven tools such as BrowserAct or Warmwind fit lighter SMB work. Straddling both dilutes the team's depth.