How 2 Make.com Scenarios + Base (formerly Baselinker) Cut Delivery Time by 72 Hours for a Dog Rescue Foundation
The Background
A dog rescue foundation Foundation Rottka Polska funds its operations by selling donated books through online marketplaces and online charity auctions.
The setup is simple on paper: volunteers across 4 separate locations receive donated books, list them for sale, store them, and ship them when orders come in.
In practice, it was anything but simple.
With around 100 orders per month and books scattered across 4 volunteer locations, fulfillment became the foundation’s biggest operational headache.
Every order required someone to figure out which volunteer had which book, split orders when a customer bought from multiple locations (which happened 75-80% of the time), create shipping labels, and notify the right volunteers.
All of this was done manually. By unpaid volunteers.
Whose actual mission was rescuing dogs.
Process before:
Process after:
The Challenge
The manual fulfillment process had four critical problems:
1. Time Drain
Each order took 3-4 minutes to process manually- checking each item against volunteer inventories, splitting multi-location orders, creating shipping labels, and notifying the right people. At 100 orders per month, that’s over 6 hours of pure admin work every month.
2. Delivery Delays
Orders placed after working hours sat untouched until the next business day. A customer ordering at 14:00 on a Friday might not have their order processed until Monday morning. The books wouldn’t reach volunteers until later that day- meaning 48-72 hours of unnecessary delay before a package even started moving.
3. Costly Errors
Manual item-checking across 4 locations inevitably produced mistakes.
Wrong books shipped to wrong customers. Each error cost the foundation approximately 25-30 PLN- the wrong item had to be retrieved and the correct one sent. For a charity operating on thin margins, every wrong shipment meant less money going to homeless dogs.
4. Refund Requests
Extended delivery times frustrated customers. Refund requests followed. For a small charity seller competing with commercial shops on the same marketplace, this was a direct hit to both revenue and seller reputation.
The Solution - Architecture Decisions
Before diving into the scenarios, two architectural decisions shaped the entire system:
Google Sheets as the volunteer-facing database.
We needed a central item database mapping every book to its volunteer location.
The obvious choice might have been to give volunteers direct access to Base (Baselinker).
We deliberately chose Google Sheets instead, for two reasons:
- Security: Volunteers don’t need access to the foundation’s central order management system. Fewer access points, fewer risks.
- Zero training: Every volunteer already knows how to use a spreadsheet. The person responsible for publishing new offers updates inventory in a tool they’ve used for years.
Email as the volunteer interface.
Volunteers interact with the entire system through their email inbox. They receive shipping labels, order details, and a confirmation button- all without logging into any platform. One click in an email updates the order status across the entire pipeline, including the customer-facing status on the marketplace.
No onboarding. No learning curve. No friction.
How It Works
Scenario 1: Order Splitting & Distribution
- A new order arrives in Base (Baselinker) from the marketplace
- Base triggers Make.com which reads the order items
- Each item is checked against the Google Sheets database to identify which volunteer has it in stock
- If items belong to multiple volunteer locations (75-80% of cases), the order is automatically split into separate fulfillment tasks
- Shipping labels are created through Base (Baselinker) for each split
- Each volunteer receives an email with their relevant items and shipping label
- The foundation office receives a Slack notification
- Order status updates to “Sent to volunteer” - visible to the customer on the marketplace
Human in the loop is necessary only if there are >5 books per volunteer. In that case, a human decides if an additional shipping label is necessary. That’s less than 1% of orders.
Scenario 2: Volunteer Confirmation
- Volunteer receives email with order details and shipping label
- Volunteer prepares the package and clicks the confirmation button in the email
- Make.com catches this action
- Order status in Base (Baselinker) updates via API to “Being processed by volunteer”
- Customer sees the updated status on the marketplace in real time
The customer experience transforms from a black box (“I ordered from a charity 3 days ago and heard nothing”) to real-time transparency (“My order was sent to the volunteer at 2:15pm and is being processed”).
The Results (18 Months of Operation)
| Metric | Before | After |
|---|---|---|
| Order processing time | 3-4 minutes manual | Under 15 minutes automated, zero human intervention |
| After-hours order delay | Next business day (up to 72h) | Processed immediately, label in volunteer inbox within 15 minutes |
| Fulfillment errors | Regular occurrence | Zero in 18 months |
| Customer order visibility | None until shipped | Real-time status updates |
| System access required by volunteers | Would need Base training | Google Sheets + Email only |
By the numbers:
- 1,800+ orders processed automatically
- ~1,400 orders intelligently split across volunteer locations
- Zero errors in 18 months of operation
- 105+ volunteer hours redirected from admin work
- At even a conservative 1% error rate, the foundation saved ~495 PLN on wrong shipments. At a more realistic 5% pre-automation error rate, that’s ~2,475 PLN kept in the rescue budget
- 2 Make.com scenarios. Zero maintenance issues. 18 months running.
The Real Impact
The numbers tell one story. The real impact tells another.
Every hour a volunteer doesn’t spend checking spreadsheets and creating shipping labels is an hour spent on what actually matters- rescuing dogs, handling adoptions, and reaching new supporters.
But there’s a compounding effect we didn’t anticipate. The time volunteers saved on fulfillment went directly into publishing more book offers on the marketplace.
More offers meant more sales. More sales meant more funding.
The automation didn’t just optimize an existing process- it scaled the foundation’s fundraising capacity.
Two scenarios. Four volunteers who never log into anything more complex than Google Sheets and their email.
Eighteen months without a single error. And more homeless dogs getting the help they need with the support of Foundation Rottka Polska.
Tools used: Make.com, Base (formerly Baselinker), Google Sheets, Slack, Email