Data should not get stuck between programs

I connect the programs you already use so they hand data to each other by themselves, with no retyping — for example shop, warehouse, accounting and carrier.

And when something jams, you see it at once — and you see what it stuck on. Below I show that along the path of one order: an example, not a sign that I only work for shops.

Arrange a call about your process

What breaks today

Failure with no message

A data handover fails from time to time without anyone being notified. Only the customer's query shows that the case is missing.

The retry that breaks more

Someone clicks “send again” because the first attempt did nothing. Now there is a second invoice or a second parcel — and the repair itself needs cleaning up.

An exception instead of a process

A return, a payment made in two parts or an order split across two warehouses falls out of the system and lands in somebody's inbox as an email: “can you deal with this?”

What it looks like after the rollout

When this makes sense

In short

Included
I map the path of the data and who is responsible for each step, connect the programs we picked, and create one place for stalled cases. There you can see what failed, what was already done, and whether the step can be run again. On top of that: tests on your own examples, an event history and a one-page guide.
What I need from you
Test access to the programs that should work together. Around twenty real cases from the past month — orders, service requests or invoices, whichever travels that path at your company. And one person who decides what counts as an error and what is normal.

The path of one order

This is how one order travels after rollout — from the shop to the parcel, including the point where it can jam. I take an order because it is the easiest to show from start to finish. I run a service request or an invoice the same way.

  1. 01

    Shop

    The system receives the order and checks that the data we settled on is complete

    an order with an identifier that survives every later step

  2. 02

    Warehouse

    It passes the items to the warehouse and takes back the reservation confirmation

    a confirmation number that travels back to the shop

  3. 03

    Accounting

    It creates the document from the order data, with no retyping

    an invoice tied to the same order

  4. 04

    Carrier

    It requests the shipping label and writes the tracking number back to the order

    a tracking number visible on the order

When something stops

The order does not disappear: it goes into an exception queue with the name of what failed and a record of what was already done. For the cases we settle on the retry is designed and tested so that no duplicate appears. That is the harder part of the work — harder than connecting the systems.

What you get

Evidence

Role
Designed and delivered by me
Scope
Over 20 production processes in IT and e-commerce, including pulling shop data through an interface and generating a document from it
Environment
Internal production system — organisation confidential
Type of evidence
Running in production — details confidential
As of
2026-08
What you can check yourself
The public article shows how I validate incoming data, catch stalled jobs, prevent duplicate runs and retry a failed step under control. It also shows when I deliberately keep a task out of automatic execution.

What this evidence does not show

I do not give the company name, do not show how it was built, and do not give its figures. So here I write what I do and how — I do not promise to save you this much time or take away that many mistakes.

Public material

How the project works

  1. 01

    A short call about one case

    We take one real case — an order, a service request, an invoice — and walk its path: where someone retypes today and where it can get stuck. The call takes 30–45 minutes, is online and free.

  2. 02

    Mapping the flow — a paid step of its own

    A small step at a fixed price: the flow map, the list of interfaces, the exceptions that need handling and the risks on the vendors' side. It ends with a document that stays with you — including if you continue with someone else.

  3. 03

    Building the slice we settled on

    I connect what we settled on and set up the exception queue. We start with one flow, not with everything at once.

  4. 04

    Review against your own cases

    We work through the cases you named yourselves, including the awkward ones: in a shop a return or a partial payment, in a workshop a job waiting on a part, in an office a document that came back for correction.

  5. 05

    Handover or ongoing support

    A guide and handover, or ongoing monthly support — depending on who runs the flow from here.

How I price it

For drawing out the path of the data you pay a figure agreed up front — you know what I do and what it costs. I give the price for the work itself only after that, because only then can you see how many programs can really be connected and how many odd cases turn up.

Common questions

Will automation remove the exceptions?

No. Exceptions will always exist — returns, partial payments, an order from two warehouses. The point is that they stop going missing: they land in a queue with the name of what failed and a record of what was already done. That is the harder part of the work, not connecting the systems.

What if our systems have no interface?

I work with the interfaces your systems provide. If they are missing and the vendor provides no access, I say so while mapping the flow, not after the contract. I also check licences and API limits — they stay with you, and I say where they may get in the way.

What if our process is not settled?

Then you have to decide first. Automating a job locks in the way you do it; it does not decide the way for you. We settle that while I map the flow, before I connect anything.

How much time will it save?

I give no figure. Until your case is measured, it would be invented. I promise something else you can check: it is visible what stalled and why, and the log lets you reconstruct what happened to a specific case.

What is not included?

No rebuilding your systems from scratch. No replacing the tools you use. No promise that exceptions will disappear.

Who is answerable for the data?

I am answerable for the flow and for making failures visible. Your company remains answerable for the data entered into the systems. Orders also raise tax and formal questions — those belong with your adviser; I say what can be handed over and recorded technically.

Can I get a price range up front?

For drawing out the path of the data, yes — you know the figure up front, and what I draw stays with you even if you carry on with somebody else. I give the price for the work itself afterwards, because only then can you see how many programs can really be connected and how many odd cases turn up. No open-ended hourly billing.

Let's talk about one flow

Describe the path of a single case at your company — an order, a service request, an invoice — from where it appears to where it ends, and where it stops most often. I will tell you whether mapping it makes sense.

Form data is used solely to answer your inquiry (details: Privacy).