What automation can and cannot join up
Automation is a trigger, a piece of data, and a destination. Most projects fail not because the logic is hard, but because one of the systems involved has no honest way in or out.
Somebody in your office receives an order on WhatsApp, copies the client's name into a spreadsheet, opens the accounting system and types the same name again, then sends a confirmation by hand. That is four minutes per order and one typo away from an invoice with the wrong RNC. Multiply by fifty orders a week and you have a full working day spent re-keying data that already existed in digital form the first time somebody sent it.
That is the problem automation solves, and it is worth being precise about what the word means. An automation is three things: a trigger (an order arrives, a form is submitted, a date passes), a transformation (extract the fields, normalize the phone number, match the client), and a destination (write a row, call an endpoint, send a message). Nothing more. If somebody sells you "automation" without being able to name those three parts for your specific case, they are selling you a diagram.
What can actually be joined
The deciding factor is almost never the complexity of your process. It is whether each system on the path has a door: a documented API, a webhook, a scheduled export, or at minimum a database you own. If both ends have a door, the work is mostly plumbing and it is cheap. If one end does not, the price triples and the reliability drops, no matter who builds it.
Things that join up cleanly, in our experience:
- Any SaaS with a REST API and API keys you control, including most modern accounting, CRM and billing tools
- WhatsApp through the official Cloud API, because inbound messages arrive as webhooks with a stable message ID
- Anything you host yourself, where the worst case is a read-only user on the database
- Email, if the format is machine-generated and consistent, and never if a human writes it freehand
- File drops to S3, Drive or SFTP, which are unglamorous and extremely reliable
Notice what those have in common. Each one gives you a stable identifier and a way to know whether a given record has already been processed. Without that, you cannot safely retry, and an automation that cannot safely retry is an automation that will eventually duplicate an invoice.
Where it breaks
The usual blockers are boring and they are not technical creativity problems. Legacy systems in the DR frequently expose nothing at all: the vendor sells the software and treats the data as theirs. Government and bank portals require a login, a captcha, and often an OTP to a phone, which means no unattended process can pass through them honestly. And PDFs are not data. An AI model can read a PDF invoice well, but "well" means it is right most of the time, and most of the time is a different engineering problem than always.
The other failure mode is identity. Joining two systems means deciding that the Maria Rodriguez in one is the same Maria Rodriguez in the other. If neither system stores a cedula, an RNC or a normalized phone number, that decision is a guess, and the automation will merge two clients or split one into three. This gets fixed with data hygiene before anybody writes code, and skipping it is why integrations get quietly turned off after a month.
If a process needs a human to look at something and judge it, automate everything around the judgement and leave the judgement alone. Half-automating a decision is worse than not automating it.
Telling a real implementation from a demo
A demo runs once, on a clean input, while somebody watches. Production runs three thousand times on inputs nobody anticipated, at 2am, when the destination API is down. The gap between those two is not the interesting logic. It is the unglamorous machinery around it, and you can audit for that machinery without reading a line of code.
Ask to see these five things before you accept the work:
- A run log: every execution, with its input, its output and its outcome, queryable for at least a few months
- Idempotency: proof that running the same trigger twice does not create two records
- Retries with backoff, and a dead-letter place where permanently failed items wait for a human
- An alert that reaches a person when the failure rate rises, not a dashboard nobody opens
- Credentials in your accounts, under your billing, so the automation survives changing vendors
The cheapest lesson here is that failure has to be loud. The simplest automation on this site is a contact form that posts to a PHP script and mails a mailbox; if that mailbox did not exist, the form would still say thank you and the message would go nowhere. That is the shape of almost every broken integration we have been called in to fix. It was not doing nothing. It was doing nothing quietly.
So the honest scope of an automation project is: map the doors first, fix the identifiers second, write the logic third, and spend a real part of the budget on observing it. A workflow that saves a person four minutes an order pays for itself quickly. A workflow that silently drops one order in fifty costs more than the manual process it replaced.