Automation With No IT Person: What Must Be Managed Externally

Most small businesses in Israel employ no IT person, and that is fine - but it changes which technical decisions are right for them. The simple rule: anything that will need knowledge to stay alive belongs with somebody else, and anything needing only business understanding can stay with you. The problem starts when that separation is never made, and the business ends up holding things it cannot maintain without knowing it.

What must be managed externally

The second row is the most commonly neglected. A backup configured once and never checked is not a backup - and the difference emerges at exactly the moment it is needed. A managed service charging a fixed fee and sending a backup confirmation is worth the difference, even in a very small business.

What "managed service" means in practice

The term sounds large and usually describes something simple: a supplier holding the infrastructure, updating it, and responsible for keeping it working - for a fixed fee. That is what every commercial cloud service is, and it is also what makes one suitable for a business with no IT person.

What does need checking before relying on it: what exactly is included. Three questions are enough - is backup included, what is the response time on a fault, and what happens to the data if you stop paying. The third is the forgotten one, and it decides whether you can leave.

The price gap between a managed service and a cheap alternative looks large in a normal month and very small in a month where something fell over. That gap is what you are actually buying.

What you can hold yourself

• Content and templates - message wording, forms, documents.
• Business rules - who approves what, when a reminder goes out.
• Settings in ready tools with a clear admin interface.
• The list of connections and who owns each one.
• Checks - confirming things work, even without knowing how to fix them.

The last point is the most important and almost always forgotten. You do not need to know how to repair in order to know how to check; somebody running a short monthly check will find a fault weeks before it surfaces in front of a customer, and that is the one capability you cannot buy externally.

Spotting a dependency before it surfaces

Three questions expose most hidden dependencies, and they are worth asking before signing rather than after. First: if you stopped working with this supplier tomorrow, what stops working. Second: whose name are the accounts in. Third: is there documentation somebody else could read.

The answer to the second frequently surprises businesses. A domain registered by whoever built the site, a hosting account opened under their email, or an API key issued under their personal account - each of those looks fine right up until the parting.

The fix is simple done early: request transfer of ownership, and confirm the registered email belongs to the business rather than a person. Once the relationship ends, the same fix depends on the goodwill of somebody who no longer works with you.

What to demand from the builder before they leave

This is what decides whether the solution lives a year or stalls at the first fault. Five things at handover:

1. All access under your accounts, not theirs.
2. A one-page document - what it does, where it runs, what breaks first.
3. The list of connections and keys, without the keys themselves.
4. What to do manually if it falls over.
5. Who fixes it and at what agreed response time.

The first prevents the worst case - a supplier who disappears with the whole system registered in their name. The full logic of dedicated accounts is in automation security for business owners.

How to check without knowing how to fix

A fifteen-minute monthly check covers most of what breaks silently, and it requires no technical knowledge at all. What to check: that the last backup succeeded and when it ran, that the automations meant to run actually ran this week, that alerts are reaching whoever should get them, and that there is no connection on the list nobody recognises any more.

All four are checkable from an admin interface without touching anything technical. What they reveal is exactly the class that produces no error: a backup that stopped running two months ago, an automation switched off since an update, an alert going to the address of somebody who left.

It is worth fixing a date in the month for it and recording the result in one line. A year of those turns the check into a picture: you can see what breaks repeatedly, and that is usually the only place worth investing in a real change.

What the real risk is

Not a fault. A fault can be survived for a day or two on manual work, which is exactly the purpose of point 4 above. The real risk is having nobody to call: the supplier is unavailable, has left the field, or was an employee who moved on.

So it is worth asking before starting: who else could maintain this. A solution built in a common tool with documentation can transfer to somebody else; a bespoke solution with no documentation depends on one person, and that dependency outweighs any price consideration.

What do you do when something breaks and there is nobody to call?

Switch to manual first, and only then start looking. That sounds obvious and most businesses do the reverse - spending two hours attempting a fix while work stops. A known manual fallback turns a fault from an event into two hours of inconvenience.

After that there are three sensible routes, in order: contact the tool's own support if it is a commercial tool, find somebody who knows that tool, and only as a last resort consider rebuilding. Many faults look complex and turn out to be an expired permission or a disconnected connection - the kind of thing vendor support resolves in minutes.

What matters afterwards: record what happened and what fixed it. That is one line which turns the next occurrence of the same fault into fifteen minutes, and it is worth the most precisely where there is nobody who remembers.

Sources

• Business automation for small businesses in Israel
• Make - error handling in scenarios