Case study: automation without trying to “put AI everywhere”

German independent publisher Büchner Verlag assembled a monthly newsletter about new books manually. An employee logged into the website, found new titles by category, copied covers, introductory copy, and standard book details into a template, added or removed sections, saved the version, and passed it for approval.

An EDITH European Digital Innovation Hub case describes how this workflow was automated with Emma, an RPA assistant supplied by WIANCO OTT Robotics. The official page was published on 26 September 2024. According to the case authors, average preparation time fell from two days to 25 seconds. With 12 issues per year and an average salary of €38,000, the calculated saving was 24 working days, or about €4,145 per year.

This is not recent news or an independent benchmark. It is useful to small businesses because it illustrates good tool selection. When data already lives in a structured catalogue and the same actions repeat every month, deterministic automation creates most of the value. A large language model should not reinvent a book title, price, link, or issue contents.

What the robot actually does

In the documented process, automation runs on the fifteenth day of every month. The robot enters the site administration area, opens the newsletter template, and checks categories for new releases. For each new book, it moves the cover, introductory text, and standard details into the right section, adjusts the template structure, saves a draft, and emails publishing management.

One detail is crucial: the newsletter is not sent to subscribers automatically. Editors receive the completed draft, inspect it, approve it, and only then start delivery. A human remains responsible for issue composition, meaning, factual correctness, and reputation.

Technically, most of the task can be stated without the word “intelligence”:

  • identify releases after the previous issue cut-off;
  • map each book category to a template section;
  • copy required fields without altering them;
  • exclude items already present;
  • validate card completeness;
  • create a reviewable version;
  • stop before external delivery.

This definition narrows the error space. If a decision can be expressed as a table or condition, a probabilistic model is usually the wrong owner.

Prefer an API, but use browser automation when necessary

RPA often imitates a person by clicking, dragging blocks, and filling forms. It can automate a legacy system without an expensive rebuild. It is also brittle: an administrator changes a button label or page structure, and the scenario may no longer find the target.

The integration order should therefore be:

1. Use the CMS and email-platform APIs where available.
2. If there is no API, read a stable export or internal database.
3. Use browser automation only for steps without a programmatic interface.

Browser flows need resilient selectors and explicit UI contracts. Playwright documentation recommends roles, labels, and dedicated test identifiers rather than long CSS or XPath chains tied to DOM position. Automatic waiting can ensure an element is visible and actionable, but it does not prove that the business result was saved.

After each meaningful step, the robot should verify state: the expected number of releases was found, exactly one draft exists, all cards are present, and the correct issue identifier can be reopened. A screenshot of an attractive page is not evidence of a committed transaction.

Idempotency: protection against duplicate newsletters

The most dangerous failure is not a clean crash but an uncertain outcome. A connection can drop immediately after “save” is clicked. A blind retry may create a second issue or add the same books twice.

Every issue needs a stable key comprising year and month, template ID, and catalogue cut-off. Each book needs its internal ID or ISBN combined with the issue key. Before creating anything, the robot looks for an existing draft with that key and continues it instead of starting again.

Useful states include:

  • `collecting` — releases gathered, cards not yet validated;
  • `draft_ready` — the template exists and passed automatic checks;
  • `approved` — a responsible person approved a specific version;
  • `sent` — the email provider confirmed delivery initiation;
  • `failed` — execution stopped with a known last confirmed step.

The send command must never be retried blindly. After a network error, the system first queries the provider for the external issue ID. The same principle applies to agents that create invoices, requests, payments, and publications.

Automatic checks before editorial review

Twenty-five seconds matters only if the draft does not require two hours of repair. Before handing it to an editor, the robot can run inexpensive deterministic checks:

  • every book has a title, cover, description, category, and working link;
  • no book appears twice;
  • no item after the cut-off date is included;
  • images load and have acceptable dimensions;
  • the number of cards matches the number of selected releases;
  • no mandatory section is empty;
  • links point to the expected domain and book page;
  • a plain-text email version exists;
  • an internal test message was delivered;
  • external sending remains blocked until explicit approval.

Where generative AI fits

An LLM can be a second layer, not the process core. It may propose a subject line, short introduction, image alt text, or section teaser. The model should receive only approved structured issue data and return drafts into separate fields.

The model should not be allowed to:

  • select books without transparent rules;
  • alter titles, authors, prices, dates, or links;
  • publish unverified claims;
  • send the email without review;
  • use subscriber personal data in a prompt without necessity.

The NIST Generative AI Risk Management Profile connects model use to measurable risks, evaluation, and accountability. For a newsletter, that means retaining source data and prompt versions, checking factual claims, filtering prohibited statements, and recording the human decision.

A local model can draft short copy inside the company perimeter. However, one monthly introduction may not justify dedicated infrastructure. Measure task volume and external API cost first, and do not send sensitive data anywhere without a documented need.

Security and access control

RPA acts with employee-like privileges, so its account should have the minimum rights required. A robot assembling a draft does not need subscriber export, payment access, or permission to change the entire website. Credentials belong in a secret manager, never inside a scenario or log.

A practical control set uses a separate service account limited to the catalogue and drafts, logs changes and send attempts, rotates credentials, and provides an emergency disable control. A manual fallback remains available after interface changes.

Automation must not remove mandatory template elements: RFC 8058, for example, specifies one-click unsubscribe.

Case economics and a model calculation

The published arithmetic is transparent: divide €38,000 by 220 working days, then multiply the daily cost by 24 days per year. The result is about €4,145. However, “two days of preparation” may describe elapsed cycle time with waiting rather than sixteen hours of uninterrupted labour. A buyer should time the local process before purchasing a licence.

Modelled annual value is:

`hours avoided × fully loaded hourly cost + prevented errors + value of faster completion`.

Subtract licensing, implementation, support, a test environment, approval time, and repairs after UI changes. If the robot removes 24 person-days but requires a specialist day every month for maintenance, the benefit is halved.

A minimum financial baseline records:

  • actual labour hours per issue;
  • the share of work that can be automated without judgement;
  • error frequency and cost;
  • the cost of a delayed issue;
  • annual licence and support expense;
  • expected editorial review time after automation;
  • payback under baseline and pessimistic scenarios.

The foreign case figure is a useful reference, not a promise for another company.

Pilot design: three historical issues and one live cycle

The pilot can start without subscriber data and without send permission.

1. Document every step and separate deterministic rules from editorial decisions.
2. Take three past issues and the catalogue as it existed on each cut-off date.
3. Configure draft creation in a test environment.
4. Compare issue contents, cards, links, and layout with the manually sent versions.
5. Simulate a failure after saving and verify that a rerun creates no duplicate.
6. Run one live month in shadow mode: the robot prepares a version while the employee completes the normal process independently.
7. Measure net labour, correction count, review duration, and support cost.

Success criteria are agreed before the test: all mandatory releases present, zero duplicates, zero unapproved sends, working links, reliable recovery, and human time reduced beyond a defined threshold.

What a manager should take away

The Büchner Verlag case demonstrates a mature automation pattern: the robot performs repetitive assembly, rules validate data, and an editor approves the issue. Generative AI is added only to fields that benefit from drafting and never gains authority to change facts or send the message.

The next step is not choosing the most fashionable model. Replay one regular process on three historical examples, count actual labour, and test a rerun after failure. If the economics and control points hold, the automation is ready for one live shadow cycle.