Sending Shopkeeper Order Status Emails for Completed Orders

Shopkeeper can notify customers when an order status changes, but many projects eventually run into one limitation: not every internal status sends a mail automatically. A typical example is marking an order as Completed and expecting the customer to receive a final confirmation.

The Real Issue

The problem is usually not mail delivery itself. The real problem is the status map. Some states are wired into the default workflow, while others exist only as internal manager labels.

What to Check

• which exact status values your installation uses for new, paid, shipped, and completed orders
• where Shopkeeper triggers customer notifications in the order update flow
• whether the Completed state is treated as a terminal internal flag instead of a mail-triggering state

A Safe Way to Implement It

The practical solution is to treat status emails as an explicit mapping instead of assuming every status should behave the same way. In other words:

• define which statuses send mail
• attach a dedicated template for each important transition
• test the transition from the manager, not just from the checkout process

In real projects that usually means adding one more condition to the order status handler so the Completed state calls the same mail service used by the earlier notification steps.

Editorial Advice

It is also worth separating the messages. A Paid email, a Shipped email, and a Completed email do not say the same thing. Once you add the extra trigger, keep the templates distinct so customers get the right message at the right point in the order lifecycle.

This old topic was short, but it captured a real ecommerce need: if a store depends on status-driven communication, the notification map should be reviewed deliberately instead of being left to plugin defaults.