What does a small first automation project actually include?

“We need better automation” leaves too many decisions open. A more useful starting point is a repeatable symptom: enquiries are copied by hand, the wrong person gets the alert, or a sales rep opens a CRM record without knowing what the prospect asked for.

Describe one recent example. Where did the work begin? What should have happened next? Where did someone have to chase information, correct a record or repeat a task? That gives the project a starting point and a visible result to aim for.

The result might be less manual entry, a dependable owner assignment or a useful next action with the relevant context attached. Pick the result first, then decide which tools need to change.

Before estimating the implementation, trace the chosen workflow through the current setup. The review should be narrow enough to stay useful and broad enough to expose the dependencies that could change the work.

For the enquiry example, this means following a few representative requests from the form to the rep’s screen. The important question is whether the rep can understand the request and act on it without reconstructing the conversation.

If the real issue is choosing what to keep or change, the repair-or-replace guide helps separate a workflow gap from a platform limitation.

A small project still needs a clear scope. Agree the trigger, the records it covers, the action it takes, the exceptions and the evidence that will show it works. Record what is outside the first change too.

The exact boundary depends on the review. A project that stays within one marketing platform or one CRM may need no new integration. A project spanning both should identify which system owns each rule so the same action is not triggered twice.

Keep a short list of assumptions and open decisions. If an assumption proves wrong, explain what changed and agree the revised scope before expanding the work.

Build the agreed change

Implementation may mean changing a native workflow, mapping fields in an existing connection or adding a small integration. Use the least complicated approach that meets the requirements and can be supported by the people who will run it.

Practical AI can help where it has a clear job, such as organizing scattered notes or drafting a summary of an enquiry. Agree what information it may use, keep the original source available and review the output where an error could matter. Only put an AI step into the operating workflow when its benefit, permitted data use and checks are clear.

Test more than the happy path

Agree test cases before calling the workflow complete. For the enquiry example, useful checks include:

• A new contact and an existing contact reach the right record without overwriting useful information.
• A repeated event does not create duplicate tasks or repeat an action unexpectedly.
• A missing field or uncertain match reaches the review path rather than silently choosing a record or owner.
• The assigned rep sees the original request, its source and the next action in the place they actually work.
• A connection failure is visible, and retrying it does not produce an extra action.
• Existing exclusions and communication permissions remain in force; test activity does not contact real prospects unintentionally.

Use agreed test data and a safe test route where available. Keep the expected and actual results, resolve failures and have the business owner review the outcome. Then agree how to release the change, check initial activity and pause or reverse it if needed.

Leave the team able to run it

A useful handoff includes a short workflow map, the rules and fields changed, test evidence, known limits and instructions for checking failures, pausing the workflow and handling exceptions. Name the person responsible for those checks.

Agree any post-release checks and support separately in the scope. Documentation and a walkthrough should make clear what the team owns after handoff and what needs further help.

You do not need a polished requirements document. A few concrete inputs make the first conversation more useful:

• One short description of the problem and what a useful result would look like.
• A few representative examples, with unnecessary personal or confidential details removed.
• The tools involved, who administers them and any known restrictions or existing automations.
• A person who can explain the day-to-day process and a person who can approve the outcome. They may be the same person.
• Known exceptions, blackout periods and the decisions your team still needs to make.

Start by describing access requirements. Do not send passwords or API keys in an enquiry. Arrange the appropriate access method once the work and permissions are agreed.

The number of boxes in a workflow diagram is a poor estimate on its own. A short flow can hide uncertain record matching, conflicting rules or a connection that behaves differently from its documentation.

Ask an estimate to make those assumptions visible. Implementation effort, optional additions and any third-party charges should be distinguishable so you can compare the same outcome.

When a separate discovery step makes sense

If nobody can identify the source of truth, the integration has unknown limits, or several teams want different outcomes, implementation may be too uncertain to scope responsibly. Start by agreeing a bounded discovery step with its own output: a current-state map, a confirmed constraint, a feasibility check or a recommended scope with the unresolved decisions listed.

A larger migration, broad historical cleanup, new data collection or a change spanning several journeys should be assessed separately. Finding that dependency is useful. It lets you choose whether to narrow the first change, investigate further or defer it before committing to a larger build.