Business Process Automation: A Plain-English NZ Guide

Illustrative technology image, not a Bestcomm team or customer project.

Start with one hand-off, not a new platform

Business process automation uses software to move defined work between steps. A modest example is turning an approved enquiry into an assigned follow-up task. It does not remove the need for a person to own the outcome.

For an Auckland or wider New Zealand business, the first question is not which AI product to buy. It is where work waits, gets retyped or loses its owner. Describe one recurring problem before discussing software. “We need a clear owner for enquiries that arrive after hours” is a more useful brief than “we need to automate everything”.

Bestcomm's CRM automation service starts with lead sources, stages, owners and required evidence. Whether an existing CRM can support a particular workflow depends on its integration options, data quality and the proposed process. Scope, platforms and pricing need to be confirmed rather than assumed.

Write a small process brief

Choose a bounded internal workflow for the first assessment. Keep payments, contractual commitments, staff entitlements and access changes outside an initial routine pilot unless the responsible specialists have reviewed the design.

A useful brief records:

• The trigger: what starts the process, and how is it recognised?
• The input: which fields are needed, and which information should not be collected?
• The owner: who checks the work and deals with an exception?
• The output: what must exist when the task is genuinely complete?
• The boundary: which decisions remain with a person?
• The fallback: how does work continue if the connection or software is unavailable?

For example, a pilot might prepare an internal task from a sample enquiry for a person to review. That is different from promising a customer a booking, sending a quotation or changing a live account. Write those distinctions into the brief.

If staff disagree about what should happen next, resolve that disagreement before connecting systems. A clearer checklist may be sufficient; new software is not always the answer.

Check the connection, not just the demonstration

A demonstration can show a successful path without showing how failures are handled. Ask the implementer to explain what happens with a duplicate submission, a missing field, an unavailable destination or a changed permission.

Questions to include in a review are:

• Does the proposed integration support the actual application and subscription we use?
• Who can authorise its access, and who can remove that access later?
• Is there a clear record of what ran and what failed?
• Can the same item be retried without creating duplicate tasks or messages?
• Who receives an alert, and how will they recognise that an item is still unfinished?
• What is the agreed method for stopping the pilot and returning to the previous process?

These are planning questions, not configuration instructions. Changes to credentials, permissions, production systems or security controls should be reviewed by the responsible technical owner. Do not use a blog checklist as approval to change them.

AI can be considered for drafting or organising information, but its output needs checking. For a first pilot, favour a visible human review point over an unattended customer-facing decision. Do not upload confidential material simply to test a feature.

Ask where personal information goes

Before using real customer or staff information, document which providers receive it, what they do with it, where it is processed, who can access it and how long it is kept. Ask what happens when a record must be corrected or removed.

The Office of the Privacy Commissioner provides guidance on sending personal information overseas. Use that guidance and appropriate professional advice to assess the actual arrangement. A provider's country, a security badge or a successful demo is not by itself a conclusion about compliance.

Use synthetic sample records for initial testing. Keep the pilot narrow and obtain the required internal approval before moving to live information or external messages.

Measure completed work, not clicks

Record a baseline before the pilot: how many relevant items arrive, how long people spend handling them, how often they need correction and how long they wait. Use the same definitions and comparable coverage when reviewing the pilot.

A button click is not proof that an enquiry arrived. A workflow showing “sent” is not necessarily proof that the intended person received a useful message. Decide what evidence counts as completion, such as a correctly assigned task visible to its owner, and test that end to end under an approved test plan.

Include unsuccessful and duplicate cases in the review. A workflow that makes the normal path faster but hides exceptions may not be an improvement. There is no guaranteed time saving or revenue result: the decision should follow the measured evidence.

Decide what happens after the pilot

Assign responsibility for monitoring, maintenance and changes before expanding the workflow. Agree how the team will record issues and when it will review whether the process is still useful.

Bring a short description of the current hand-off, the applications involved, the desired result and the constraints to the first discussion. Avoid sending passwords, one-time codes, payment information or sensitive incident details.

To discuss a possible next step, contact Bestcomm. Start with the business problem and confirm the proposed scope before committing to implementation.