Automation Lab

Hands-on programme where ops and finance teams automate their own workflows with engineers on call.

Most operations and finance teams already know which tasks eat their week. What they lack is time, a safe place to try things, and someone to ask when a flow breaks. This programme gives them all three: they pick their own workflows, build the automations themselves, and have Arclight engineers on call to unblock them.

It was built for ops and finance teams who run their own routines on the tools they already have. It does not depend on any platform: the output is a plain written process, readable by anyone, buildable with any tool, and useful even without one.

Who should attend

Ops and finance teams, and anyone who owns a recurring process. A team's repeatable work fits into three shapes. Each has its own template and its own module.

• Workflow, one per recurring process: invoice matching, month-end reporting, supplier onboarding. Inputs, steps, owners, exceptions.
• Decision, one per choice, dated. What was chosen, why, what was rejected, where the rule now lives.
• Runbook, one per automation you ship: what it does, who owns it, how to pause it, how to fix it. When to apply, steps, checks.

A process that proves its worth is promoted into a standing workflow, and the pilot notes stay as a record. Both point to each other.

Why the programme is built this way

An automation does not understand a process the way a person does. It needs the inputs, the steps, the owner and the exceptions written down, with nothing left to assumption. It breaks the work into small, checkable actions and follows them literally. A step that lives only in someone's head is a step that will fail. Every convention in this programme follows from that:

1. One name per thing, always spelled the same. A flow called "invoice check" and one called "AP review" will be taken for two.
2. Every step stands alone. Anyone should be able to pick it up cold. Each step names its owner and its input in the title.
3. Rules are short sentences. Who does what, with which input. "Finance approves invoices above the agreed limit." That sentence becomes a check.
4. Absolute dates, never "last week".
5. Define each acronym once per page, at first use.
6. Header on every workflow, with the same fields each time. It anchors ownership and lets a script derive labels for reporting.
7. One idea per page. Link to other pages by title, and by name in the text.
8. No secrets, no personal data. Describe the process, not the customer. Examples are shared in the group, so keep them anonymous.

The workbook explains each step with the mistake it avoids.

How to run it, with no new tools

1. Copy the templates into a shared folder of your own and create three sections: workflows, decisions and runbooks.
2. Build from the templates. The worked example shows the expected level of detail; its six parts reference each other, so you can see how it fits.
3. Before you build, run the readiness check with your facilitator. It checks the process owner, the inputs, the exceptions, the access needed and a few data-handling rules. It reports and never changes anything.

Your process is the source of truth. Whatever tool you build on top is an implementation you can replace.

From a manual process to a first working flow

This is the path we teach in the programme, in a shared workspace reached through the tools your company already uses. Buying new platforms is out of scope here; the first call covers the options.

1. Point the build at your own workspace. Set the access in the programme brief or your team's settings; keys stay with you.
2. Check the scope. The brief maps each team to a list of candidate processes. The default is one process per team. Each automation needs one owner, so for a company you will want clear ownership per process (see below).
3. Check the pages. The review must report zero gaps.
4. Build. The first time, on an empty workspace; in later weeks, only the changes. The facilitator walks each team through one process at a time: write it down, check it, build the smallest working version, test it on real cases and hand it over. Allow a few sessions per process. The first workflow takes longest. Later ones go faster, and engineers stay on call throughout.
5. Verify. The proof is not that the flow ran. It is a log without errors, a result that matches a hand-checked example, and a colleague who can explain what it does. The facilitator checks this with you, and afterwards you repeat it on your own.

What to watch for on the way

• Automate one process at a time per team. Two builders editing the same flow at once will overwrite each other, so agree who holds the pen.
• Never paste raw data into a public tool. Use the approved workspace, which keeps work traceable and reviewable.
• A changed process is a new version. Retire the old flow first, or two will run side by side.
• Do not trust a single test run. When nothing fails, a flow may simply have skipped its work. Check the output itself.
• If an automation touches a shared system, give it its own account, so that only one process changes the records.

Teams and access rules

For one person, a shared folder is enough. For a company, access matters more than convenience. Each automation should read and write only what its owner may, and nothing wider. So map each workflow to a clear perimeter, such as one team or one system.

Each perimeter then holds its workflows, approvals and logs together, and the type of work is recorded in the title, where reporting picks it up as a label. The simplest working model for a small company is one owner per perimeter, everyone else read-only.

Status

This programme reflects Arclight's way of working on automation, adapted to each group. The examples cover ordinary company work: invoice matching, onboarding, reporting, supplier queries. It suits some teams better than others, and we say so in the first call. Tell us where a method fails and we will change it.

Contact

Questions about the programme? Write to contact@arclight.im.