Internal business systems and workflow automation for SMEs

Don’t replace your ERP to fix a process problem. In most SMEs the ERP or accounting system does its core job well enough; the pain sits in the processes around it: approvals by email, planning in Excel, reports assembled by hand, data typed twice. Use workflow automation for the data flows between the systems you keep, and build a small internal tool for the one process no standard product covers. Replace a core system only when it actually blocks you.

Spreadsheet, low-code, standard module or custom tool?

Each option has a point where it stops working. Spreadsheets fail once several people edit them or their data must reach another system. Low-code connectors struggle when logic branches or failures need handling. A standard module turns into workarounds when your process differs from the vendor’s model. Custom tools pay off for processes specific to your business, as long as the first version stays small.

Option	Good for	Breaks down when
Spreadsheets and email	One owner, low volume	Several people edit, or data must reach other systems
Low-code connectors (Zapier, Make, n8n)	Simple triggers between cloud tools	Logic branches, volume grows, failures go unnoticed
Standard software module	Processes your ERP vendor already models	Your process differs and workarounds pile up
Custom internal tool plus integrations	Core processes specific to your business	Scope is not controlled; start with one process

How is an internal system put together?

We start with the data model: which objects exist (job, order, customer, machine), which system owns each one, and who may see or change what. The internal tool is a web application with role-based access and an audit log, backed by PostgreSQL. Background jobs run the workflows and sync with the ERP or accounting system through its API, on a schedule or on events. Each run is logged, so a failed sync appears on an error list with its cause.

Two habits from our own projects carry over. Business rules (thresholds, time windows, priorities) are settings, not code, so you can change them without a release. And integrations with systems you don’t own are read-only unless writing is needed. In the affiliate reactivation system we built for a SaaS client, the connection to the client’s tracking platform can call only an allow-list of read operations, and a test proves a full import makes no write calls.

Example: a building-technology company with 40 technicians

Illustrative scenario, not a client project.

A heating and plumbing company near Zurich takes service orders by phone and email. Planning happens in an Excel sheet, technicians fill in paper job reports, and the office types hours and material into Abacus for invoicing, often a week later.

The first version covers one process: the job report. Technicians see their jobs on a phone, record hours, material and photos on site, and the customer signs on screen. A completed job creates the invoice data in Abacus through its REST API. Unbilled jobs and open orders appear on a dashboard. Phase two moves planning out of Excel into the same tool; phase three adds maintenance contracts that generate service jobs automatically.

What about data protection and hosting?

The revised Federal Act on Data Protection (FADP), in force since 1 September 2023, requires privacy by design and by default (Art. 7) for data processed in Switzerland, and the GDPR (Art. 25) sets the same principle in the EU. For internal systems this means role-based access, an audit log, deletion rules, and a hosting location decided before the build, not after.

Internal tools often store employee data, including hours and locations, so we document what is stored and why. Under the FADP, companies with fewer than 250 employees are generally exempt from keeping a record of processing activities, unless they process sensitive data on a large scale or run high-risk profiling.

How does a project run?

1. Discovery. We sit with the people who do the work, map the process and count the manual steps.
2. Architecture. Data model, system ownership, roles, integrations, and the scope of the first version.
3. Build. Short iterations, with a test environment your team can try early and often.
4. Launch. One team or location first, with the old process available as a fallback.
5. Iterate. Feedback from users, then the next process on the same foundation.

After discovery you receive a fixed-price or phased proposal. The broader question of which systems to keep, connect or replace is covered in digital transformation.