Short answer. A European B2B company ran its operations by hand. Every order, every sales question and every new partner needed a person. We did not replace its systems. We put an operations layer on top of them with n8n and made Slack the only interface. Ten processes now run in production. Four rules shaped all of them: work where people already are, a person clicks the button when money is involved, check every action after it runs, and make every failure visible.
This is a real client project. The client stays anonymous, so figures are adjusted for confidentiality. The ratios are real.
What was the problem?
The company sells to business customers across Europe. Its customers pick the supplier who delivers on time and in full. A customer collects orders all day and expects one delivery at a fixed hour, so any delay on our client's side breaks the customer's promise to its own buyers.
Behind that promise, the work was manual:
- Someone told the warehouse about each order and worked out the ship day.
- Someone changed order statuses by hand.
- Before every set assembly time, someone checked each open order line by line.
- Sales questions kept landing on the same members of the development team. Each answer meant checking several systems by hand: repetitive work that pulled them away from building the product.
Growth was limited by how much a few people could do. When one of them was away, the work waited.
Why build on top of the existing systems?
The core systems worked. Replacing them would have taken a long time and stopped nothing from going wrong in the meantime. Their release cycles were also slow, so waiting for new features inside them was not an option.
So we connected what was there: the order and warehouse systems, customer data, the finance and compliance tools, and project tracking. n8n runs the workflows. Slack is where people see results and press buttons.
Which processes did we automate?
The ten processes fall into three groups.
Orders: from order to warehouse
- Instant warehouse message. A new order reaches the warehouse in Slack the moment it is created, with its priority and ship day already set. Each order has a set assembly time, and that time together with the order size decides the ship day.
- Express handling. Express orders notify the teams that need to act. Regular orders follow the normal flow without extra messages.
- Trusted customers. Every hour, orders from approved pay-later customers move into work without waiting for a person.
- Test order cleanup. Every evening, orders from test accounts are cancelled, so they leave the warehouse queue and the sales reports.
- Missing order lines. Open orders are checked every hour before assembly against what the customer actually sent (see below).
Sales questions and status checks
- A sales bot in Slack. It reads a question in plain words and checks the status across departments itself: compliance, finance (for example, a VAT check), orders and stock. Actions with consequences run on a button and are checked afterwards.
- A weekly status list. Every week, sales gets the customers still waiting for a decision from another department, so nobody waits in silence.
Partners and reporting
- Partner onboarding in one thread. A manager posts a customer ID and picks the connection type. The system sets the partner up in every system involved, requests the access it needs and reports back in the thread.
- Daily partner checks. Open setup steps are followed up until each partner is fully connected.
- Reporting. Weekly partner order counts, report reminders, and roadmap statuses rolled up automatically from work done in other projects and systems.
How does one process work end to end?
The missing-order-lines check shows the pattern best.
Key customers add lines to one open order through an API all day. At the set assembly time, the order is closed and goes to picking. Sometimes a line never reached the order, and the client heard about it from a complaint.
Now it works like this:
- Hourly check. In the hours before assembly, every line the customer added through the API is compared with the lines actually in the order.
- Read again before alerting. A gap is read again from the primary source after a short wait. One data source once lagged behind, and an early alert would have doubled lines.
- Manager alerted. Slack shows "4 lines missing in this order" with two buttons: "Add 4 lines" and "Fixed manually".
- One click. The manager clicks "Add 4 lines". The system adds them, re-reads the order and confirms. The button is replaced by "All lines added".
- Blocked item, if any. If an item is blocked and cannot be added, the people who can unblock it are called into the thread straight away.
The rule in step 2 came from a real false alarm. It is now a standing rule in every workflow we build: check again before you alert.
How did we test the sales bot?
We did not launch the bot on gut feeling. We took thousands of real requests from the sales channel history and labelled them by hand with the correct answer. Every change to the bot's rules is replayed against the full set before it goes live.
The share of questions the bot ignored fell from 36% to 5%. On its first run, the roadmap roll-up moved 12 items with 0 errors and 4 warnings.
What does it not do?
- Anything involving money needs a person to click: adding order lines, express labels, access requests.
- The bot routes questions by keyword rules and still misses some topics. Each miss feeds the next round of rules.
- Payment reminders and month-end invoice collection are built and waiting to be switched back on.
What changed for the team?
Sales managers ask the bot and get an answer in seconds. The developers who used to field these questions get only the unusual cases and stay on their own work. What they knew lives in the system, so a change of owner no longer resets it.
Account managers act on a Slack message with a button instead of checking every order before assembly. The warehouse picks from tasks that arrive with priority and ship day set. Partner managers connect a new partner in one Slack thread, and nobody moves roadmap statuses by hand anymore.
What can you take from this for your own operations?
- List the handoffs, not the systems. The waste sat between sales, the warehouse and partners, not inside any one tool.
- Put the interface where people already work. For this team that was Slack.
- Keep a person on every money decision. A button costs seconds and keeps trust.
- Check results, not just errors. The most dangerous failure is a step that silently never ran.
- Give every alert one named owner.
If you want to apply this to your own processes, the automation blueprint asks the same questions and returns a plan. Our business process automation work usually starts with one process like the order check above.
FAQ
Why Slack and not a new dashboard?
The team already worked in Slack all day. A new dashboard is one more tab nobody opens. A Slack message with a button reaches the right person where they already are, and the thread keeps the history of what happened.
Why n8n and not custom code?
n8n let us connect the client's existing systems quickly and show each workflow to the people who own it. The rules matter more than the tool. Every rule is written down, tested and owned by a named person, so the same logic could later move to custom code if a process outgrows the workflow tool.
How do you stop an automation from doing damage?
Four habits. Anything that involves money waits for a person to click. Every action is checked after it runs. A suspicious result is read again from the primary source before anyone is alerted. Every failure goes to a named owner, never to a channel where everyone assumes someone else will act.
Real client project, client anonymised. Figures adjusted for confidentiality, ratios kept.