Furniture Store Software Problems: The 7 That Cost You Written Business, and How to Avoid Them

Why does a special order project turn into a full ERP replacement?

A dealer starts with one complaint: nobody can tell a customer where her sectional is. Six weeks later the proposal includes point of sale (POS), accounting, sales tax, vendor catalogue ingestion, commissions and a website rebuild, and the price has tripled. The reason is that once you open the order record, everything is attached to it, and every department has a legitimate grievance about the enterprise resource planning system they live in.

Replacing the whole thing is almost always the wrong call for a mid sized dealer. STORIS, ECi PROFITsystems, Genesis Advantage and Myriad Eclipse encode decades of category knowledge in the least interesting places: sales tax by jurisdiction, vendor catalogue structures, financing plan handling. You would rediscover all of it at your own expense, and you would spend most of the budget before touching the thing that is actually costing you money.

The fix is the hybrid, and it is the shape of most furniture work we deliver. Keep the enterprise system as the financial system of record. Build the operational layer on top: the special order promise chain and delivery readiness, meaning purchase orders, acknowledgment ingestion, unit level allocation and route eligibility. In Digital Heroes delivery experience that first release runs $60k to $130k and ships in 12 to 16 weeks. The full platform spanning point of sale, warehouse mobile, delivery, service, protection plans and reporting runs $150k to $400k phased over 6 to 12 months, and it is a decision you can make later with better information.

What goes wrong migrating order history and open deposits?

Pulling fifteen years out of a PROFITsystems or Myriad database is commonly four to eight weeks on its own, and it is the line item dealers underestimate every time. Three parts of it are genuinely hard.

Custom option configurations were usually stored as free text. A cut and sew sofa with contrast welt, nailhead trim and a firmer seat cushion exists in the old system as a paragraph a salesperson typed, with no consistency between stores or between years. You cannot parse that into structured attributes reliably, and you should not try for closed history. Decide which orders need structured options, which is realistically the open ones, and treat closed history as searchable text.

Open deposits have to reconcile to the penny against your books, and they are real customer money. Your controller signs off on the deposit total, not your developer. Run the extract three or four times against a staging environment with the controller checking totals before anybody discusses a cutover date.

Partially delivered orders are the ones that break cutover weekends. An order where the nightstands were delivered in March and the dresser is still on a container exists in an in between state that most import scripts flatten. Identify every partially delivered order before the extract, count them, and handle them deliberately rather than letting the loader make a decision on your behalf.

Why do vendor acknowledgment feeds break after launch?

The promise chain depends on ingesting every vendor acknowledgment, and vendors do not cooperate in any consistent way. Some acknowledge through a portal, some through electronic data interchange via SPS Commerce, and some through a portable document format file attached to an email from a rep's personal address. Each route fails differently.

Portals break when the vendor redesigns a page, because a scraper is a maintenance commitment rather than an integration. Budget for it explicitly and expect two or three breakages a year per portal. Electronic data interchange is the most stable route, and it breaks least, but a vendor changing a segment or adding an exception code you have not mapped will silently drop revisions. Email breaks when the rep leaves and the new rep sends from a different address, or when a document layout changes enough that extraction confidence drops.

The fixes are structural. Treat extraction confidence as visible data, so a low confidence acknowledgment goes to a review queue rather than quietly writing a wrong ship week against a purchase order line. Alert when a vendor has sent nothing for longer than their normal cadence, because silence looks identical to good news. And store every acknowledgment as a dated revision rather than overwriting the previous date, so you can see slip counts and hold vendors to a median slip figure in a buying meeting at High Point.

What happens when delivery readiness and card handling are not covered?

Two gaps cost real money and both get deferred during scoping.

The first is delivery readiness. If the sales order flips to complete when any line has a received quantity, a crew will be dispatched to a stop where the nightstands arrived and the dresser did not. In our client data a failed white glove stop lands between $140 and $260 in direct cost, plus a customer who took the day off work and a review that says so. Readiness has to be a computed state: every line in the delivery group physically received, tagged to that customer, staged in a scanned bin and free of open damage flags, plus a balance check so no crew arrives to collect money that was already paid online. Routing tools like DispatchTrack and Elite EXTRA will route what you send them. They cannot decide that a stop should never have been built.

The second is card data. You take deposits at the counter and balances at the door, which is two card acceptance environments. The correct design keeps card numbers entirely out of your system using a tokenising processor and point to point encryption validated terminals, so the build only ever holds a token and the last four digits. That keeps most of the application out of Payment Card Industry scope and turns the annual exercise into a manageable self assessment. If any developer offers to store cards to make collecting delivery balances smoother, end the conversation there.

Should you build custom or configure what you already own?

If you are one or two stores under roughly $8M, buy STORIS or Genesis and live inside it. Custom software at that size is a hobby, and the money belongs in inventory.

Before deciding, check whether the constraint is the product or the process. Many dealers who feel trapped have never set up vendor lead times properly, never used the reserve flag consistently, or have a warehouse that does not scan. Fix the data discipline first, because a custom build on top of an undisciplined warehouse produces the same wrong numbers faster.

Build when the signals are specific. You employ someone full time whose job is reconciling two systems. You have more than one warehouse and stock moves between them by phone call. Your delivery failure rate is above five percent and you cannot explain why. Your website quantity is wrong often enough that you stopped showing quantity. You are acquiring dealers and every acquisition is another instance to babysit. Or the one that settles it: your process is your edge, you are the group in your market that delivers when promised, and the packaged system forces you to operate like everyone else.

How do hidden costs get into the quote?

• Vendor count, priced as a single line. Each electronic data interchange relationship is discrete effort and each portal without an interface means scraping plus ongoing maintenance. A quote that says vendor integration without naming a number is not a quote.
• Migration. Four to eight weeks is normal and it belongs as its own workstream with its own budget, not as a task inside the build.
• Financing flows. Synchrony, Wells Fargo Retail Services, Progressive Leasing, Snap Finance and Acima each have their own process. A dealer running four of them is running four integrations, and dealers routinely forget to mention three.
• Warehouse hardware and connectivity. Scanners, label printers and reliable coverage inside a metal building are real capital and real site work, and offline tolerance in the scanning app is engineering rather than a setting.
• Running costs. Hosting, document and photo storage for delivery and damage capture, mapping calls and per device management fees all recur. Ask for a modelled monthly figure at your current volume.

What separates a build that works from one that fails here?

The first differentiator is the data model, and you can test it on the first call. Ask a prospective developer to sketch a cut and sew sofa with seven option attributes, allocated to a named customer, sitting in transit on a container. If the answer is a stock keeping unit with variants, they will build you a web shop. The right answer involves a configuration record, a unit record with an explicit state machine, and an allocation edge to a sales order line. Available to promise then becomes a computed value that the website, the point of sale and the sales floor all read from the same place.

The second is that the warehouse and the truck were designed for, not designed at. The people who use this software hardest did not choose it and cannot stop to troubleshoot. Ask what happens to a scan when the signal dies at the back of the building, and what happens to a delivery capture when a crew has no coverage in a basement. A developer who has not built for offline has not shipped this category.

The third is a phased cutover with a real fallback. Go live on one store or one warehouse first, keep the old process available for the first month, and do not schedule cutover in a peak delivery week or over a holiday weekend.

Finally, settle ownership before anything is signed: the source, the infrastructure definitions, the continuous integration configuration and a documented handover, in your own repository from the first commit. At Digital Heroes the client owns all of it. Your order history and your open deposits are customer obligations, and they must not sit in an account someone else controls.