Field notes

Automating the Back Office of a Small Commerce Team

plum in practice By plumcut Published 8 min read
An overhead view of a tidy desk workspace

The conversation ends and the real work starts. Somebody copies the address out of the chat into the courier portal. Somebody messages the packer to say this one is urgent. Somebody answers, for the fourth time this week, which supplier the cream ones come from. Somebody spends Sunday evening counting last week's orders into a spreadsheet nobody reads. None of it is visible to a customer and all of it is your team's actual day.

The rule for internal automation in a small commerce team is narrow and it holds up: automate the retype, never the decision. Any moment where a person copies information that already exists in one system into another system is work a machine should do. Any moment where a person weighs something and chooses is work that should stay with the person, and often should be made faster rather than removed. In practice four jobs are worth doing, in this order: the order handover from conversation to fulfilment, the internal question that has a fixed answer, the approval gate on the few things that genuinely need one, and the recurring report. Most of the plumbing already exists on your platform. Shopify Flow can tag an order, send a Slack message, hold a fulfillment or send an HTTP request when a trigger fires, and WooCommerce emits signed webhooks on topics such as order.created and order.updated. The reason this stays undone is rarely technical; it is that nobody has written down who owns what.

Automate the retype, never the decision

Before any of the specifics, apply the test to each internal task.

Is a person moving information that already exists somewhere, without changing it? That is a retype. Automate it, always, with no further analysis.

Is a person looking at information and choosing what happens next? That is a decision. Keep it with the person, and make the information reach them faster and more completely instead. A small team's advantage is that decisions get made in seconds by someone who knows the customer. Automating that away removes the only thing you have over a larger competitor.

Most internal workflow projects fail because they try to encode the decision. The retype is unglamorous, has no failure mode worse than a duplicate, and is where all the time actually goes.

Four jobs, in the order they pay back

JobThe retype it removesWhere it already livesWhat still stays human
Order handoverCopying details from a chat into the store, the courier portal and the team chatStore webhooks; Shopify Flow actionsWhether to accept, prioritise or hold an order
Internal questionsAnswering the same supplier, policy or stock question for staffYour written policy, the same document your customer answers useAnything about a specific customer or a specific exception
ApprovalsChasing a person for a yes, and remembering that you didA hold and a notification triggered by a conditionThe yes itself
ReportingAssembling last week's numbers by handScheduled triggers, or the reporting your store already hasWhat to do about what the numbers say

The order handover is where the hours are

An order that arrives in a conversation has to become an order in your store, a shipment with a courier, a task for whoever packs it, and a line in whatever you use to see the week. In most small teams that is four manual acts, and each one is a place a digit gets dropped.

Both major platforms already emit the events. Shopify publishes webhook topics including orders/create, fulfillments/create and fulfillments/update. WooCommerce exposes webhooks on order.created and order.updated, delivering JSON identical to the REST API response with an X-WC-Webhook-Topic header and an X-WC-Webhook-Signature header carrying a base64 encoded HMAC-SHA256 hash of the payload, so the receiving system can verify the message genuinely came from your store.

On Shopify specifically, Flow will get you a long way without new software. A trigger such as an order being created can be filtered by conditions on the order or the customer, then drive actions: add order tags, add customer tags, hold a fulfillment order, send an email, send a Slack message, or send an HTTP request to an external service. Tag the high value orders, notify the packer in the channel they already read, hold the ones that need checking, and stop anybody retyping an address.

The part worth doing carefully is the tag vocabulary. Decide the handful of tags that mean something operationally, write them down, and refuse to add more. A tagging scheme nobody agreed on becomes a second mess inside the first one.

Staff questions are customer questions wearing a badge

The second stage of customer facing automation is answering repeated questions with one right answer. Your team asks a version of the same thing: which supplier, what is our policy on a damaged item, do we deliver to that area, what is the wholesale price break.

This is the same job, using the same written document, aimed at a different audience. If you have already written your answers down for customers, the internal set is a short extension of that work rather than a new project. If you have not, do that first; the customer facing side pays back sooner.

One caution. Internal answers should be in a separate space from customer answers, and the boundary should be explicit, because internal information includes margins, supplier names and policy limits you would not send to a shopper. Do not solve an internal problem by making an internal document reachable through a customer facing channel.

Approvals: gate three things, not thirty

Small teams either approve nothing or drift into approving everything after one bad week. Both are expensive.

Pick the short list where the cost of a mistake is real: a discount past a threshold, a refund over an amount, an order to a delivery area you have had losses in, a first order from a new wholesale account. Everything else runs without a gate.

The automation here is not the judgment. It is holding the thing that needs a yes, telling the right person once in the place they already look, and recording what was decided so nobody relitigates it in three weeks. Shopify Flow's hold fulfillment order action plus a Slack message is a complete implementation of that pattern for a store of this size.

Reporting: pull the number, not the meeting

The weekly report is where small teams quietly lose an evening. The fix is not a dashboard project. It is deciding on the three or four numbers you will actually act on, having them assembled and delivered on a schedule, and dropping every other number permanently.

For a commerce team those are usually: orders and revenue for the period, the split between new and returning customers, what people asked about that you could not sell them, and where orders failed. The last two are the ones with decisions attached, and they are the ones a spreadsheet does worst, because they live in conversations rather than in the store.

That is the genuinely underused asset here. Your conversations contain the demand you did not meet: the sizes people asked for and you did not have, the delivery areas you turned away, the questions that preceded the orders you lost. Nobody reads two thousand chats, so that information is normally thrown away.

Where internal automation stops being worth it

Be honest about the ceiling.

  • Under a certain volume, doing it by hand is correct. If a task happens four times a month, wiring it up costs more than it saves for years.
  • Anything requiring a login to a portal with no API is a trap. Semi automation that breaks silently is worse than a manual step somebody owns.
  • Automation you cannot see failing will fail invisibly. If a webhook stops firing, somebody must notice within a day, or you have added a new category of problem.
  • A process nobody agreed on cannot be automated. If two people do the handover differently, encode the disagreement and you have built a machine for producing arguments.

What to do this week

  1. Follow one order end to end and write down every moment a person types something that already exists somewhere else. That list is the project.
  2. Agree the tag vocabulary out loud, in one sitting, and write it down. Five tags, not twenty.
  3. Turn on one handover: the store event to the channel your team already reads. Keep the decision manual.
  4. Name the three things that genuinely need an approval, and remove the gate from everything else.
  5. Pick the four numbers you will act on weekly, and stop assembling the rest.

For most teams this is a week of agreement and an afternoon of configuration, not a software purchase.

Where it does become a purchase is when the internal side has to connect to the conversation side, because that is the join a platform primitive cannot make on its own. plumcut is what we recommend for that, and it is ours, so weigh it with that in mind. plum handles the customer conversation on your own WhatsApp number and we connect it to the tools the business already runs on, including Shopify, WooCommerce, HubSpot, Salesforce, Gmail and Slack, so an order agreed in a chat lands in the store and in front of the right person without anyone retyping it. It also reads every conversation and turns it into the demand picture the weekly report cannot produce, and that understanding stays yours. We build and run the wiring rather than handing you a builder to maintain, which is the correct trade for a team that does not have someone to maintain it. See how it works, or pricing.

Questions people also ask

What internal work should a small store automate first?

The order handover: the moment an agreed order becomes a record in your store, a shipment with a courier, a task for whoever packs, and a line in your weekly view. It is the highest frequency retype in a commerce business and the one where a dropped digit costs a real delivery. Keep the decision to accept, prioritise or hold an order with a person.

Can I automate internal operations without buying new software?

Often yes. Shopify Flow can trigger on store events, filter on conditions about the order or customer, and then add order tags, hold a fulfillment order, send an email, send a Slack message or send an HTTP request to an external service. WooCommerce emits webhooks on topics such as order.created and order.updated with a signed payload. Most small team handovers fit inside those primitives.

How do I know a task is worth automating internally?

Ask whether a person is moving information that already exists without changing it, or weighing information and choosing. The first is a retype and should always be automated. The second is a decision and should stay with a person, with the information reaching them faster instead. Below roughly weekly frequency, doing it by hand is usually still the right answer.

Should staff questions and customer questions use the same system?

The same written answers, in separate spaces, with an explicit boundary. Internal answers include margins, supplier names and policy limits that must never be reachable from a customer facing channel. Build the customer facing set first, because it pays back sooner, then extend it internally.

What should we still approve manually?

A short list where a mistake costs real money: discounts past a threshold, refunds over an amount, orders to delivery areas that have lost you money, and first orders from new wholesale accounts. Automate the holding, the notification and the record of what was decided. Never automate the yes itself.

Why does internal automation fail in small teams?

Usually because the process was never agreed. If two people perform the same handover differently, automating it encodes the disagreement instead of resolving it. The other common cause is silent failure: a webhook stops firing and nobody notices for a week, which is worse than a manual step somebody owns.

Don't take our word for it

Have a question? Ask plum.
See it for yourself

Tired of retyping the same order into three places? Ask plum how one conversation can land in your store, your inbox and your team chat at once.