Responsibilities made concrete

Not necessarily. Many routine tasks — moving form responses into a spreadsheet, sending standard reminders — can be set up in-house using features already included in common office software. A consultant is more likely to be useful when a process crosses several systems, handles personal or financial data, has many exceptions, or when nobody internally has time to record it objectively. A reasonable test is whether the firm could write the discovery record itself. If it cannot, outside help with discovery may be the most valuable part of an engagement.

At minimum: a SIPOC outline agreed by the process owner, a current-state BPMN diagram with roles and systems, an exception log, a list of the data and access involved, and a short list of open questions with named people to answer them. These artefacts belong to the firm and should be stored in its own file storage in editable formats. A discovery that produces only a slide deck of recommendations leaves little to check later, and makes it harder to brief a different supplier if the firm chooses one.

The business that runs the process generally remains answerable to its customers, staff and regulators for the outcome, whether a person or software carried out the step. Contracts can allocate liability between the firm and a supplier for defects, which is a matter for legal advice. Operationally, the firm should name one accountable person for each automation, as described under ongoing ownership, so that errors are noticed and handled rather than argued over. This is general information, not legal advice.

Under UK GDPR, a DPIA is required where processing is likely to result in a high risk to individuals, and the Information Commissioner's Office publishes guidance and screening checklists to help decide. Automations that profile people, make significant decisions about them, or combine data sets on a large scale are more likely to need one. Even where it is not required, a brief screening note shows the question was considered. For your own situation, consult the ICO's guidance directly or a qualified data protection adviser.

Rule-based automation follows explicit instructions: if a field matches, do this; otherwise, do that. AI components, such as machine-learning classifiers or large language models, produce outputs based on patterns and can vary between runs. Proposals sometimes use the terms loosely. It is reasonable to ask which steps use rules, which use AI, how AI outputs are checked and what happens when confidence is low. The answers affect acceptance testing, data protection review and how much human oversight remains in the process.

Ideally during scoping, before any build work starts, by the process owner and the consultant together. Each criterion should describe observable behaviour, and each case in the exception log should have at least one criterion. Given–When–Then examples work well because they read as plain English and can be run as tests. The process owner, not the builder, should run user acceptance testing and sign off, with results filed alongside the scope statement. Criteria written after the build tend to confirm what was delivered rather than test it.

Usually the person who owns the underlying business process — the finance lead for an invoicing automation, for example — rather than whoever happens to be most technical. That person needs a run book, a current diagram, an access register and a change log, plus a deputy who has performed the routine checks. IT support may hold credentials and platform administration, but accountability for what the automation does should sit with the business. A RACI table, as shown under engagement scope, makes this explicit.

It is a sensible consideration. Lock-in arises when an automation runs on accounts the firm does not control, uses proprietary configurations nobody else can read, or is documented only in the consultant's own systems. Practical safeguards include holding platform licences in the firm's name, requiring diagrams and configuration exports as deliverables, and asking how another provider would take over. Platforms such as Power Automate, Zapier, Make and n8n differ in how portable their workflows are, which is worth asking about during scoping.

Compare what each proposal commits to deliver rather than how it describes itself. Useful questions: does it start with discovery, and what artefacts will that produce? Are deliverables worded so they can be checked? Are exclusions and assumptions listed? Who writes and who signs acceptance criteria? What does handover include, and is ongoing support separate? Is data protection inside the scope? Proposals that promise specific financial returns before any discovery has taken place give you little you can verify.

No. Everything on quibscrewhangout.lol is general, evergreen information written to help owner-managers ask clearer questions and keep better records. It does not take account of any firm's circumstances, contracts or regulatory position. For decisions involving law, data protection, tax, employment or significant financial commitments, speak to a suitably qualified professional or consult the relevant public authority, such as the Information Commissioner's Office for data protection matters in the UK. More on how the material was put together is on the about page.