Who this is for
An operations manager or business owner who inherited a tangle of Zaps, scenarios and Airtable automations built by several people, some of them gone.
Nobody can say what all the automations do, two of them seem to do the same job, a failure alert goes to nobody, or a plan limit forces a decision about what to keep.
The result
You receive an inventory of every automation on the agreed list, a recorded decision for each overlap, a smaller set in which every remaining automation has a named owner and a failure alert proven by a test, and a short runbook. You accept the finished set, not each internal step.
What is included
- Up to ten automations in total, or the number agreed in the written proposal, on one or two platforms; the proposal names the list. Automations in those accounts beyond the agreed list are counted and recorded as out of scope, and are quoted separately before any work on them
- An inventory of the agreed list: each automation's trigger, the apps it touches, its last run, its owner and how it would alert
- Identification of overlaps and loops, and a recorded keep, merge or retire decision for each, made by you
- For each automation you switch off, the switch-off time and a catch-up checklist: what to compare in the source app for the period it was off, because switching an automation back on does not replay what it missed
- Merged or corrected copies for the decisions that need one, tested with synthetic data, and a failure alert for every remaining automation
- A short runbook for the remaining set
- Scheduled scripts and other code jobs are inventoried only if the polling job is added; otherwise a script found in the accounts is named as out of scope
You receive
- The inventory of the agreed list, with each automation's owner, trigger, systems, last run and alert route, and a count of any automations left out of scope
- A list of overlaps and loops with the decision you recorded for each, and for each switched-off automation its switch-off time and catch-up checklist
- Corrected or merged copies with change notes, and the synthetic test results
- Alert routes for every remaining automation, with a received test alert for each
- A runbook: what each remaining automation does, who owns it, what an alert means and what to check first
What is not included
- Switching live automations on, off or deleting them: you do that from our notes
- Moving automations from one platform to another, or building new ones
- Changing plans, credentials, connected accounts or billing
- Merging or deleting duplicate records that earlier automations already created
- Real customer data in tests, or any message sent to a real contact
What we need from you first
- The platforms and roughly how many automations each holds
- What triggered the tidy-up: duplicates, a missed failure, a plan limit or a departing builder
- Who can decide what to keep, and who switches changes on
- Do not send passwords, API keys, customer data or an account invitation in the first enquiry
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- The inventory lists every automation on the agreed list as shown by each platform's own list on a stated date, each with an owner, trigger, systems, last run and alert route, and states how many other automations the platforms hold that are out of scope.
- Every overlap or loop identified has a keep, merge or retire decision recorded by you, every retired automation was switched off by you rather than deleted, and each has its switch-off time and catch-up checklist recorded.
- Every remaining automation has a named owner and an alert that delivered a test alert to the shared place.
- Each merged or corrected copy passed an agreed synthetic test before you switched it on.
You accept the finished set: the inventory, the decisions, the alerts and the runbook. You switch the changes on, and you can send any item back with comments before you accept.
When we would stop or decline
- Nobody on your side can decide what each automation is for or which to retire
- The accounts cannot be inspected without credentials that give access to live customer data
- An overlap involves automations outside the agreed list, or the accounts hold many more automations than the agreed number, and the list cannot be settled without them; we re-quote with you before going on
- Most automations can only be tested against live customers
Questions
Do you delete the automations we retire?
No. You switch them off and keep them for an agreed observation period, so any dependency nobody remembered can be found and the automation can be switched back on. Switching back on does not replay what was missed while it was off, so we write a catch-up checklist for each.
Do you build new automations in this project?
No. This project consolidates what exists. New builds are separate jobs.
How is this different from keeping automations monitored?
A project ends when the agreed set is inventoried, decided and alerted. Monitoring and repair is a standing service that continues month after month.
Why does the project cost more than the separate jobs it contains?
The component jobs each fix one automation or one alert. The project adds the inventory of up to ten automations, the decisions on which overlap, merged copies, the catch-up checklists and the runbook, and you accept the finished set rather than each step.
Price and terms
From £1,950 · untested offer price. The payment schedule is set in the written proposal. Nothing is charged until you have agreed it.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.