You can automate plenty. What is worth automating?

A form sends its data to a spreadsheet. One system prepares a reply. Another creates a quote and schedules a message. Each step can look convincing in a demonstration.

If the team keeps losing time on the same steps, it is natural to look for a solution. To choose well, we also need to know what still needs checking after automation, so the time saved is not swallowed by corrections.

Real work includes incomplete cases: an outdated price, an unclear inquiry, an unresponsive integration or a customer asking for something outside the standard offer. Judge the automation by what happens then, too.

“We can automate it” describes a technical possibility. The business still needs to know the benefit, the costs and who will keep it running.

Start with the process you have.

We write down what goes into the process, what must come out and who uses it. Then we identify the stable rules, the necessary data and the frequent exceptions.

If two people define a “qualified inquiry” differently, automation can reproduce the confusion faster. If prices have no up-to-date source, a well-worded reply can still be wrong.

For fixed-rule operations, a standard integration may be enough. AI can help when interpreting a text or preparing a response variant. The choice starts with the task and how the result will be checked.

In its guidance on building AI systems, Anthropic recommends starting with the simplest solution that meets the need, adding complexity only when justified. The principle is useful in marketing projects too. Anthropic: building effective agents

Not every stage needs the same level of autonomy

Imagine a made-to-order furniture company. Some messages ask for showroom opening hours, some describe dimensions and materials, and others request a final price or an exception to the usual terms.

We can organize the process into three levels. This classification is a working model for this example, not a universal rule for every business.

An acknowledgment should not automatically promise availability, a final price or a delivery date. The message needs to stay within what the system can verify.

Savings are counted after checks and exceptions

Suppose an activity takes 12 hours a month. After automation, three hours of monitoring and two hours of exception handling remain. The net time saving is seven hours.

In the hypothetical model below, implementation costs RON 2,500, including setup, testing and initial training. The additional recurring cost is RON 200 per month, covering the assumed tools and external maintenance. Amounts exclude VAT and do not represent NOT MORE. prices or proposals.

The calculation is 7 × 100 − 200 = RON 500 per month, then 2,500 / 500 = 5 months. We assume the same volume of activity and stable costs. The model does not discount for the time value of money and is not a promise to recover the investment.

Saved hours are not automatically cash received or salary costs eliminated. If the team cannot put them to useful work, the assumed economic benefit does not become a cash saving. The additional direct expenditure is still real.

Volume matters. With the same price assumptions, only two hours saved monthly would have a value of RON 200, equal to the recurring cost. In that scenario, the model does not recover the initial investment through time saving.

What happens when information is missing

Before launch, define what happens when the system cannot find a product, receives conflicting information or cannot confirm submission. It might ask for clarification, flag a case for review, or stop that action and notify its owner.

If an inquiry is saved but the notification fails, retrying should not create a duplicate. The system needs to recognize the same inquiry and repeat only the unsuccessful step.

We define who can stop automation, where errors are seen and how manual work continues. These are practical operating conditions, especially when the process communicates directly with customers.

The same discipline applies to advertising automations

When a platform can combine assets or generate variations, agree on which sources it may use, what must stay accurate and who reviews the outputs available. An expired website offer becomes a problem if it feeds current advertising.

Include source checks, settings reviews and correction of unsuitable variations within the tool’s limits. Automation reduces repetitive work; the team still needs to check the result against the approved product and promise.

Test situations that resemble real work.

A useful pilot includes ordinary inquiries, missing information, duplicates and cases that should go to a person. We compare the result with the requirement and measure total time, including corrections.

We track correct completion, how often intervention is needed, how many errors occur and what impact they have. A high completion rate is not enough if messages contain wrong prices or lose important information.

After launch, we review data sources, costs and exceptions. An automation built for an old offer may need to be updated when the business changes products or the commercial process.

How do we know whether the experience improved?

A faster process for the team can become harder for the customer. If the assistant closes a conversation but the person still lacks an answer or has to repeat everything on the phone, completed conversation counts describe system activity without demonstrating resolution.

Before a pilot, we would define the outcome for each journey. For a product question, check whether the answer is correct and sufficient. For an appointment, check whether the booking exists. For a complex inquiry, a complete handover to the right person may be the useful outcome.

Evaluating an action’s actual effect separately from the agent’s claim is also discussed in Anthropic’s material on agent evaluations. Applied here, a confirmation message needs to be checked against the operation it describes.

We would assess four things together: accuracy, customer effort, total team time and progress toward the objective. Accepted answers, corrected information, necessary handovers and failed operations should remain distinguishable. A colleague taking over can be the correct outcome for a case rather than an automation failure.

Comparison also needs context. People who choose to use an assistant may have different questions or intentions from other visitors. A higher conversion rate in that group does not establish that the assistant caused the difference. To assess its effect, we would design a test with comparable groups and decide in advance what to measure and when the evidence would support a decision.

We would preserve direct access to information and the team. Visitors should be able to correct a detail, understand the next step and choose another route. Trust grows when the system helps without making a conversation a condition for moving forward.

How we make the choice at NOT MORE.

We start from repetitive activity and its actual cost. We may propose a simple rule, an integration, AI assistance or keeping a manual step. We explain what is automated, what is checked and what remains a person’s responsibility.

For us, a useful implementation is one the team using it can operate and understand. The benefit is checked in the full process, after we include monitoring and maintenance.

Three questions before implementation

• How much time and how many errors could we save at the actual workload?
• What can the system do independently, and when must a person take over?
• How do we verify the benefit after costs, corrections and exceptions?

What repetitive activity would you like to simplify?

Describe the current steps, the monthly volume and the situations that require intervention. We can discuss whether a simple rule, integration or AI assistance is worth evaluating in a well-defined project.

From a working rule to an automation people can use

NOT MORE. can design the process, choose tools and build an automation or integration. We start with the required information, decisions and exceptions, then configure or develop the appropriate solution. An existing tool may cover the need; custom development makes sense when the requirements justify it.

In a fictional example, quote requests are copied manually from email into a spreadsheet. We could build the transfer to a CRM and the assignment rule. But we also need to check duplicate messages, missing fields, absent colleagues and integration failures. An alert is useful only if it reaches someone who knows what they can do.

The client validates business rules and names the users. We implement, test and document the agreed components and can include training. We establish who can stop the workflow, how to work manually for a while and how to confirm normal operation has resumed.

Monitoring, maintenance and reporting depend on the automation’s role and the impact of an error. For a discrete project, we hand over the solution and agreed checks. In an ongoing collaboration, we monitor runs, exceptions and required changes. Progress is evaluated through useful work completed and errors reduced in the team’s real working conditions.

The team needs to be able to adopt the solution

The people using an automation should understand what changes in their working day. We involve them in testing relevant situations and agree training, manual intervention and who can request help. A limited first stage can show whether the rules and interface are usable before expansion. The time needed to adapt and administer the solution belongs in the project evaluation; it should not disappear behind a promise of efficiency.