Business Automation
EN
Discuss your task

Automating the manual work in a trading company

I connect the accounting system, the website, marketplaces, CRM, the bank, email, e-documents and other services so that data moves between them without being re-typed.

Below are the five processes the work most often starts with.

I do not replace a system that works. I remove the manual work between systems.

1. Shipping and paperwork in one click One window instead of the accounting system, the e-document service, the carrier's portal, the label printer and a message typed to the client by hand. 2. B2B portal for partners and dealers A routine order the partner places themselves: they see their own prices and stock, repeat a past order and get the invoice without waiting for a manager. 3. Accounting ↔ website ↔ marketplaces ↔ CRM Orders, stock, prices and statuses stay in sync between your systems with no manual re-typing. 4. Documents from email into the accounting system An invoice, a goods receipt, a payment or a price list arrives by email — the system reads the attachment and prepares the document in the books. A person checks it instead of typing it all again. 5. Analytics and control Sales, margin, stock, settlements and the deviations that matter — with no report-gathering by hand.

You do not have to automate everything at once

Usually we start with the one process that regularly takes the most time: shipping, carrying orders across, supplier documents, reports, or the work with partners.

If an off-the-shelf module already solves the task well enough, I will not suggest writing it again. Custom automation is for where your process runs across several systems or has rules of its own.

How the work goes

  • A conversation — 30 minutes on your process.
  • Audit and plan: the first stage, its result, its deadline and its price.
  • One stage of work, with no advance payment.
  • Acceptance: you see the finished result.
  • Payment for the accepted stage.
  • The next stage — on the same model.

What stays with you

The code, the settings, the access and the documentation belong to you. The system can run without my continued involvement, and another developer can maintain it if needed.

Did not find your process?

These five areas are not a complete catalogue. If people in your company regularly carry the same data across, put together the same document, or walk the same route through several systems — describe it in your own words.

On the first call I will say whether custom automation makes sense here, whether an off-the-shelf service would do, or whether nothing needs changing at all.

If you are not a distributor, the same areas are described in your words: online shops and marketplaces, retail chains, manufacturers selling their own output.

Take my process apart

FAQ

Questions we hear most often

Do we have to replace our accounting system?
No. The accounting system stays the source of the data, and the automation works around it: it takes what is already in there and puts the result back. Moving to another system is a large project of its own, and it is rarely what removing manual re-typing requires.
We already have an off-the-shelf module. Why custom development?
If the module solves the task properly, you do not need it, and rewriting it makes no sense. Custom development is for where the process goes further than one exchange: across several systems, with rules of your own, or with steps the module simply does not have.
When does automation make no sense?
If an operation happens rarely, takes a few minutes and causes no trouble, it is cheaper to leave it as it is. Nor is it worth writing a custom solution when an off-the-shelf module covers the task properly. I would start by counting the processes that repeat every day, run across several systems, or already need a person of their own for the manual part.
Will we become dependent on you?
The code, the access and the documentation stay with you. The solution must not require my daily presence to keep working, and another developer should be able to understand the system without rewriting it from scratch. After launch I can maintain it or hand it over to your developer.
What if an integration fails?
Good automation must not pretend everything succeeded. Critical operations need statuses, an error log and a clear exception path: what is retried automatically, and what is shown to a person to check.
What happens if a third-party service changes its API?
Integrations depend on outside systems, so such changes do happen. What matters is that a failure is visible and can be traced, and that the code and the documentation stay available for maintenance.
What access to our data do you need?
Only what a particular integration needs. Where possible I use separate API keys, technical accounts and minimal rights instead of access to the whole accounting system. The exact arrangement depends on the systems being connected.
Will our documents be sent to AI services?
Not necessarily. AI is used only where the task needs it and where the way of handling the data has been agreed. For critical or structured operations there is often no need to send anything to a language model at all.

Take my process apart