The status map: building your store's process into OrderPilot

Ask the salesperson what In Production means and she points to the vendor's confirmation. Purchasing says it means the PO went out. The warehouse says the sofa has not arrived. Meanwhile, the customer heard “it's being made” six weeks ago and has had no news since.

A useful status means the same thing wherever the order is opened. OrderPilot's status map puts the staff steps, customer-facing stages, and connections between them in one place. Start with what must be true before an order moves, give that decision an owner, and let the map carry the agreed process.

Define the promise behind each status

A status is a claim about the order. Sent to Vendor says the purchasing instruction has gone out. In Production should mean whatever production evidence your store has agreed to require. Ready to Ship should tell the delivery team something dependable about the goods. Color helps people spot a label; the definition makes it useful.

Ask the people who sell, buy, receive, and deliver the furniture to describe the same recent order. Look for the point where their descriptions diverge. Sometimes a missing status is the problem. Often the store already has enough labels but no shared rule for entering or leaving them.

Write the rule in ordinary language before opening the editor. “Purchasing checked the vendor's acknowledgment against the signed configuration” is useful. “The order looks fine” will become a different test for every person. The special-order playbook gives the broader procedure behind those decisions.

Keep the map small enough to explain at the desk. A distinct step earns its place when it changes who acts, what must happen, or what the customer should understand. One department does not need a private status for every email it sends. Even a sectional has fewer moving parts than some office whiteboards.

Understand the four building blocks

The status map combines staff statuses, customer groups, connections, and the Next status button. Each answers a different question about the same sale.

Statuses belong to your working process. Customer groups simplify that process for the person waiting for a sofa. Connections describe the move between statuses. Next status reads those connections on the individual order, so the general process becomes a practical answer at the desk.

The workflow automation and controls discussed here are on OrderPilot Professional. Staff need the relevant permissions to change settings or act on orders. The customer portal is available on Growth and Professional; the same customer-facing wording also matters for the emails your store sends.

Start with the defaults and separate the branches

The defaults give the store a useful vocabulary before it adds local steps. Draft holds work in preparation. Pending Review supports a review decision. Quote represents the quotation stage, and Order represents the placed sale. Changes Requested and Rejected describe different review outcomes; they are branches, not milestones every successful sale must visit.

Purchasing progress includes Partially Sent to Vendor and Sent to Vendor. Receiving progress includes Partially Ready to Ship and Ready to Ship. Shipping uses Partially Shipped and Shipped; delivery uses Partially Delivered and Delivered. Those distinctions matter when a sofa is ready but the matching chair is still waiting for fabric.

In Production and Quality Check are sample working steps. Your store can decide what evidence they represent and whether they belong in its routine. A custom Delayed, Out for delivery, or Balance due step can help where someone has a real decision to make. These are examples to add, not universal defaults.

Built-in system statuses keep their names and cannot be switched off or deleted; custom statuses, non-system defaults, and customer-facing groups can be renamed. Use the editable descriptions and customer wording to make the process understandable. There is no need to rename Sent to Vendor into a phrase that hides what actually happened.

Do not put every status in a single linear parade. A quote that needs correction goes back for work. An order cancelled before production does not travel through delivery. A partial receipt leaves outstanding goods. Draw those branches because the exception is where an otherwise tidy map often stops being useful.

Give customers a simpler set of stages

Every store starts with seven customer groups: Quote, Confirmed, In production, Ready, On its way, Complete, and Cancelled. Each can cover several staff statuses. You can edit the group's name and explanatory text so it sounds like your store and says something useful about the wait.

Here is one possible sofa journey. It is a process illustration, not a requirement to configure every store identically.

flowchart LR
  subgraph Q["Quote"]
    D["Draft"] --> PR["Pending Review"] --> QU["Quote"]
    PR --> CR["Changes Requested"]
    CR --> PR
  end
  subgraph C["Confirmed"]
    O["Order"] --> SV["Sent to Vendor"]
  end
  subgraph P["In production"]
    IP["In Production"] --> QC["Quality Check"]
  end
  subgraph R["Ready"]
    RS["Ready to Ship"]
  end
  subgraph W["On its way"]
    SH["Shipped"]
  end
  subgraph F["Complete"]
    DE["Delivered"]
  end
  subgraph X["Cancelled"]
    CA["Cancelled"]
  end
  QU --> O
  SV --> IP
  QC --> RS
  RS --> SH
  SH --> DE
  O --> CA

The customer should not have to interpret an internal review label or guess whether Ready means “ready at the factory” or “ready at our warehouse.” Put the distinction in the group text. If another appointment is needed, say that. A group name alone cannot explain every arrangement.

A status hidden from customers preserves the last customer-visible stage, or In progress where there is no earlier stage to show. That helps with private administrative work, but it is not a reason to conceal a changed delivery expectation. Send a clear update when the customer's plan is affected. The public and private statuses guide develops the wording.

Build connections around evidence

Every connection has When, Only if, and Then. When identifies the event or staff action. Only if checks the conditions on the order and its lines. Then describes the resulting move and accompanying actions. Read the connection as a sentence and see whether the team can agree that it is true.

Automatic connections respond to events OrderPilot records, such as signing, payment, PO sending, receiving, shipping, delivery, or collection. They are useful when the event itself supplies the evidence. A completed receiving record can support a readiness decision in a way that an estimated arrival email cannot.

Staff connections wait for someone to press Next status. Use them when the store needs judgment: reading an acknowledgment, comparing a changed finish, or confirming that a production milestone means what the vendor says it means. A staff connection can also wait for a recorded condition before it becomes available.

Actions can add tags or notes, notify staff, control the status email, or enable customer payment. Choose actions that support the next person's job. A tag that nobody uses becomes decoration. A note explaining the handoff can save the next person from reopening the whole conversation.

Follow a sofa through an automatic and a staff move

Consider an illustrative Madison sofa order in performance velvet with walnut legs. The PO has been sent, so the order is at Sent to Vendor. The vendor replies with the accepted configuration and a production schedule. Purchasing reads the acknowledgment and compares the fabric, finish, quantity, and timing with the PO.

The store's staff connection leads from Sent to Vendor to In Production. Its When is the staff action. Its conditions reflect what the store wants verified before that action is available. The employee presses Next status only after the acknowledgment supports the move. A sent email alone has not silently become proof of production.

The Then actions can notify the next responsible person and send the chosen customer update. That update should explain the confirmed stage without inventing a delivery appointment. If the vendor's dates differ from the customer's expectation, the order desk resolves and communicates that difference as part of the same handoff. Later, the sofa arrives and receiving records the accepted quantity. The map can move an order whose required goods are all received to Ready to Ship. If the order also includes an outstanding chair, the partial condition must lead to partial readiness instead. The status should follow the recorded quantities rather than the optimism of whoever unloaded the first carton.

The example shows why some steps belong to software and others belong to staff. The system can evaluate quantities that have been recorded. A person still needs to decide whether the vendor's acknowledgment matches what was sold. The automatic connections guide explains the event-driven side in more detail.

Set priority before several connections can match

Connections from a status share a priority list, and the first matching connection wins. Order the list intentionally. A broad condition placed above a more specific condition can capture an order before the specific route is considered.

Take a mixed order with received chairs and an outstanding table. A connection for complete readiness and another for partial readiness need conditions and priority that make their meaning unambiguous. Test the mixed order, then test the same order with every piece received. The result should differ for a reason you can explain.

Write down what should happen when no connection matches. Sometimes waiting is the correct result: no vendor acknowledgment, no received goods, or no completed staff review. A missing move should send the employee to the unresolved work, not encourage them to manufacture an event.

The app's system connections appear on the map with their logic locked. Their actions, email choice, and place in the priority list can be adjusted. Treat that distinction as part of the design: the recorded event keeps its meaning while the store decides how to organize the work around it.

Use Next status to finish the right piece of work

Next status turns the map into an order-specific menu. The ready move appears alongside other possible moves, including those that are waiting. A waiting row gives staff a reason, so they can see whether the missing piece is a recorded event, a condition, or their own unfinished work. Read a waiting condition literally. If a move waits for receiving, the answer is to record the actual receipt when it happens. If the customer has paid but the payment is not reflected, resolve the payment record. Bypassing the wait by choosing a more advanced label can leave the next department acting on a false premise.

Staff can still choose a status by hand when their permissions allow it and the map does not fit the situation. A hand-picked status holds until something read by its connections changes. Record why the exception was needed and decide whether the map needs a lasting improvement. The Next status guide covers the desk conversation behind that choice.

Decide which moves deserve a customer email

Every status change does not need a customer email. The connection's Send the status's email choice and the status's notification setup determine what is sent. Internal corrections and review work can stay quiet while meaningful purchasing, readiness, or delivery milestones receive clear updates.

Read the proposed message together with the destination group's wording. If both say “ready,” they should mean the same kind of readiness. The email should also say what happens next: your team will arrange delivery, the customer can review the order, or the store will contact them when the vendor confirms more.

Separate the public update from the internal handoff. A receiving colleague might need to know which bay contains the cartons. The customer needs to know which pieces have arrived and whether there is anything to do. One message should not attempt both jobs.

Use the Activity history to inspect what happened, including the trigger recorded for a move. When someone asks why an order advanced, begin with that history and the connection rather than guessing from the current label.

Test a draft before changing the live process

Status-map edits stay in a draft until publication. That gives the owner and order desk space to read the proposed process together. Use Test on an order to see which connection would fire against an actual order's recorded facts.

Pick different situations deliberately: a signed quote awaiting review, a PO sent without acknowledgment, a partly received order, and an order with goods already delivered. These are suggested test cases, not a claim that the store needs a separate map for each situation. Test both a move that should happen and a move that should wait.

Inspect the actions as well as the destination. A correct status with the wrong customer email is still the wrong outcome. The status-map testing guide gives a practical way to record expected and observed results.

Publish makes the draft live and rejects a loop of connections that would keep firing. Publication also offers to check open orders now. Decide deliberately whether existing orders should be evaluated immediately, after reviewing the records likely to change and the messages the proposed connections would send.

Publishing a map is not a replay of the store's entire history. Existing orders retain their real facts, and future evaluations use the published rules. Tell the desk what changed and which open orders you checked so staff do not interpret a fresh move as fresh physical progress.

Version history keeps published maps and can restore an earlier version to the draft. Review and publish that restored draft if it is the right correction. Restoring rules does not retract customer messages or undo furniture already handed over.

Keep workflow progress separate from Shopify payment and fulfillment

Shopify tracks order, payment, fulfillment, and return states separately, as its order-status guide explains. Paid describes payment; it does not prove that the sofa was manufactured, received, or delivered.

OrderPilot adds the store's operational process around those facts. Shopify payment and fulfillment events can drive OrderPilot connections, while the staff statuses describe the special-order work. Keep the two views consistent without expecting a single label to replace every underlying record.

That distinction is especially useful for partial orders. A customer can have paid the agreed amount while only some goods are ready. A shipment can leave while another line waits for fabric. The Shopify and workflow status comparison helps explain the difference to staff.

How to do this in OrderPilot

Start in Settings › Quotes & orders › Statuses with a paper description of the process. Keep the defaults that fit, define any necessary custom steps, and choose customer groups whose wording your team can comfortably say aloud. Add connections only after their evidence and owner are clear.

Use this worksheet during the discussion. Replace the owner roles with names or agreed cover arrangements before the process goes live.

If approval is part of your store's process, include the manager review loop rather than treating a correction as a completed sale. If a handoff still depends on a particular employee remembering it, name a backup and make the information visible on the record.

Finish by walking a sample order through the map with the person who will cover the desk on a busy day. They should be able to explain the present stage, the next action, and the customer message without calling the owner. Then write down the store's process so the agreed meaning survives the next staffing change.

Sources

1. Understanding your order statuses — Shopify Help Center.