Business automation: choose a process and verify the result

A good first automation takes one clearly defined manual task off your hands. For example, it transfers a website enquiry to the CRM and alerts the person responsible if the transfer fails. Choosing that process starts with observing your work; tools and a developer come later.

This guide helps you prepare a process brief, assess the economics and write a test plan yourself. Every number in the example is illustrative: it is neither a SignM client result nor a promise of savings. You need a spreadsheet and access to the people who perform the process.

Open the free process brief or download the CSV spreadsheet template. No registration is required. Read the worked example below, then replace its assumptions with your own.

1. Find work that actually repeats

During an ordinary working week, record recurring actions. Be more specific than “handle enquiries”: open the email, copy the phone number, find the customer, create an enquiry, assign a sales representative. Record waiting and active work separately: a day waiting for a supplier's reply cannot automatically become a day of labour saved.

For each action, collect four observations: how often it occurred, how many minutes it took, how much rework it required and what happens when it goes wrong. If the week was unusual, label it accordingly. Do not extrapolate a seasonal peak across the whole year.

• Transferring website enquiries to the CRM. Check whether the fields are consistent, whether you can access the form and CRM, and whether someone owns the process. This is a pilot candidate if incoming enquiries can be saved before transfer.
• Preparing a tailored proposal. Find out how often an employee must make a non-standard decision. Start with a draft reviewed by a person.
• An occasional complex calculation. Check whether there are repeatable rules and enough work to justify automation. A good template may be sufficient for now.

Choose a process with a clear start and finish, an owner and an acceptable cost of error. High frequency helps but is not essential: an infrequent action may still justify automation if it is critical and manual checks are unreliable. In that case, the objective is to reduce risk, rather than produce an impressive number of hours saved.

2. Define the input, result and boundaries

Describe the process in one sentence: “After a valid website enquiry has been saved, create an enquiry in the CRM, assign an owner and record the transfer result.” Then define a valid enquiry and a confirmed result. A green “workflow completed” indicator does not, by itself, prove that the sales representative received the correct record.

• Input: the event, its unique identifier, time, source and required fields.
• Rules: field validation, assignment and matching against existing customers.
• Output: the created enquiry's identifier and a verifiable transfer status.
• Exceptions: incomplete data, an unavailable CRM or an ambiguous customer match.
• Out of scope: qualifying the request, calculating prices and making commitments to the customer remain the sales representative's responsibility.

An event identifier and a customer's phone number solve different problems. Delivering the same enquiry twice must not create a duplicate. However, two different enquiries from the same phone number may be separate requests. Deduplicating by phone number alone can lose a genuine enquiry.

Describe current behaviour before proposing improvements. If employees assign enquiries differently, agree on a rule first. Automation cannot decide who owns a disputed customer relationship for you.

3. Complete the brief: a website enquiry example

This is an illustrative example for a small team. Its timings and limits are sample requirements that you must agree for your own process.

Do not put passwords or tokens in the brief. Record who controls access and which actions the integration may perform. An operational log usually needs only the event identifier, time, step and error category. Not every employee or technical notification needs the full text of an enquiry.

4. Calculate the economics without promising to replace an employee

Start with current labour. Our illustrative company receives 20 enquiries a day; transferring each takes four minutes; there are 22 working days in the month. That gives 440 operations and 1,760 minutes, or 29 hours and 20 minutes.

Some work remains after automation. Suppose checking each enquiry takes one minute, 22 exceptions require another five minutes each, and maintenance takes two hours a month. These are assumptions for the pilot to confirm or replace.

At an illustrative hourly cost of RUB 600, the released time is valued at RUB 10,900. If services cost RUB 2,000 a month, the illustrative benefit after those costs is RUB 8,900. With one-off implementation costing RUB 45,000, the calculation gives about 5.1 months. This demonstrates the formula; these are not SignM prices or a commercial offer.

Released hours are not cash in the bank: salaries may stay the same. Record how you will use the time and verify its value. Include setup, training, data migration and staff time in one-off costs; include services, infrastructure, support and monitoring in recurring costs. Do not count the same support both in the contractor's price and again as a separate expense.

Recalculate with lower volume and more exceptions. If the result becomes unattractive, reduce the pilot or postpone the project. Do not justify weak economics with invented future revenue.

5. Decide whether AI is needed

Moving a known field into another field usually does not require AI. A fixed rule is easier to verify: “If the selected category is support, assign the support team.” AI is more useful for interpreting free text, suggesting a category or preparing a summary.

Separate suggestions from actions. In the first pilot, AI can suggest an enquiry category for a person to approve. Automatically changing prices, sending commitments to customers or deleting data needs a separate decision and controls. Confident wording from a model is not evidence of correctness.

• Test clear, incomplete, contradictory and unusual enquiries.
• Allow an “unable to determine” result instead of forcing a category choice.
• Record prohibited actions and data that must not be sent to the selected service.
• Compare the result with simple rules: a keyword list may already solve the problem.

The process owner must understand how to correct a model error and who will see an uncertain result. Add AI after reliable enquiry storage and transfer monitoring are in place.

6. Plan for failures before connecting services

Retries do not fix every error. Temporary service unavailability differs from a missing required field. Temporary failures call for limited retries with delays; persistent errors need human review. This approach is described in Microsoft's retry pattern documentation.

In n8n, you can assign a separate error workflow to handle failed executions; see the official n8n documentation. An error notification does not itself save an enquiry or prevent a duplicate: those checks belong in the process.

You also need reconciliation: how many enquiries were accepted, transferred, queued or require a person? If an event was lost before a workflow started, execution logs alone are insufficient. Comparing them with the original enquiry list helps reveal such losses.

7. Run a small pilot and check the result

Limit the pilot to one source, one operation type and one owner. Start with test data in a separate environment. Then compare the system's proposed actions with manual decisions without allowing it to change live records. Only then enable an agreed, small flow under supervision.

Choose a period that covers a normal working cycle. Two successful enquiries do not establish reliability, and the absence of a rare error for a week does not prove that error handling works. Reproduce unusual situations separately.

1. Valid enquiry: exactly one enquiry is created with the correct fields and owner.
2. Repeated event: no second record appears; the previous result is available.
3. New enquiry from the same customer: a separate request is retained.
4. Incomplete data: a person can access the enquiry and understand the problem.
5. Unavailable CRM: the enquiry remains saved and monitoring shows it waiting.
6. Lost response: checking again does not create a duplicate.
7. Automation stopped: the team can continue processing manually.
8. Resumption: the queue is processed without repeating completed actions.

For every test, save the input example, expected result and actual result. Then measure time spent checking, handling exceptions and maintaining the process. Continue when the result is useful, all events are accounted for and the team can handle exceptions. If there are losses, duplicates or unexplained states, stop expanding and fix the cause.

8. Prepare stop and recovery procedures

The stop control must halt automated actions while preserving accepted enquiries. Record who operates it, where to view the queue, how to hand work to a sales representative and how to reconcile completed work before restarting.

A backup matters, but restoring a database does not undo an email already sent or an action in an external system. A full restore may also overwrite later, valid changes. Distributed operations need planned compensating actions; Microsoft's documentation explains the distinction. In the CRM example, correct duplicates under an agreed rule while preserving the enquiry history.

Ask an employee who did not build the workflow to follow the stop instructions using test data. If this is impossible without the integration's author, handover is incomplete.

9. When not to buy automation yet

• No one owns the result or investigates errors.
• Rules change daily and employees have not agreed on a shared process.
• The required action already exists in your system but has not been tested.
• A document template or a small configuration change solves the main problem.
• You lack access to the data source or permission for the required actions.
• The budget covers implementation but allows no time for testing and maintenance.

This does not mean abandoning improvement. Remove the specific obstacle first: appoint an owner, collect observations, organise fields or test the CRM's built-in feature. You can then make a concrete purchasing decision.

10. Brief a contractor

Share the completed brief and anonymised examples. Ask for separate estimates for the first pilot and subsequent development, a list of recurring costs and a demonstration of the test procedure. You can use this wording:

We need to automate [one operation] between [source] and [destination]. We currently perform [volume] operations per [period], spending [time]; the main errors are [list]. Success means [verifiable result]. Our owner is [role].

The pilot includes [boundaries] and excludes [exceptions]. We need incoming events to be saved, protection against repeated execution, a state log, a manual fallback and recovery instructions. Acceptance tests are attached. State the one-off price, recurring costs, required access, limitations and handover deliverables. If a built-in setting solves the task, propose that option.

You can first complete the process brief yourself and discuss it with your team. If you prefer to delegate implementation, the document will help you compare proposals and check the work. You do not need to buy development to obtain the brief.

A short glossary for discussions with a developer

• Trigger — an event that starts a workflow, such as saving a form submission.
• API — a documented way for programs to request data and perform actions in one another.
• Webhook — a notification from one system to another about an event. Receiving it does not mean the whole operation has finished.
• Queue — a saved list of events awaiting processing.
• Idempotency — repeating an action does not produce an additional result. For an enquiry, it means no duplicate when the same event is transferred again.
• Pilot — a limited test of the process, economics and error handling before expansion.
• Rollback — returning to an agreed working state; external actions sometimes require a separate compensating operation.