Printing Company Software: Fixing Estimating, Press Scheduling, and Shipping Before They Cost You the Job

Why estimating and scheduling software makes or breaks a commercial printer

A commercial printer is one of the last businesses where the price is quoted before anyone knows what the job actually costs. Your estimator looks at a spec: 5,000 sheets, 4/4, 100# gloss text, aqueous coating, fold to a 6-panel, ship to three addresses. He knows the press. He knows the paper is on a 9-week lead from Veritiv. He knows the folder has a jam problem on 100# text. And he has 40 minutes because the broker on the other end is shopping three shops. So he prices it from a spreadsheet built in 2019 that nobody has re-costed since the last two rounds of paper increases, adds a fudge factor, and sends it.

Then the job hits the floor and reality arrives. The run takes 3.5 hours of makeready instead of 1.5 because the pressman had to chase color on a stochastic screen. The folder eats 400 sheets. The bindery queue pushes the job past the ship date, so you air-freight one of the three drops at $340 to protect the account. The job quoted at $4,200 lands at maybe $3,900 in true cost, maybe $4,600. Nobody ever finds out which, because the job costing report in PrintSmith requires the pressmen to clock in and out of every operation on a shop-floor terminal, and on the floors we have walked they do it maybe six times out of ten. The four they skip are exactly the jobs that went sideways.

That is the actual condition of most $8M to $40M printers we work with. They are running PrintSmith Vision, EFI Pace, Avanti Slingshot, Tharstern, or Printavo, held together by an estimator's private Excel workbook, a whiteboard in the plant manager's office that is the real press schedule, and a shipping process that lives in ShipStation with tracking numbers copy-pasted back into email. The MIS is a system of record for invoicing. It is not a system of record for how the shop actually runs.

Problem one: estimating cannot price the way you actually sell

Here is the scenario that breaks every off-the-shelf estimator. You have a repeat customer who orders six SKUs of packaging inserts, different quantities, same stock, same colors. Ganging them onto one 40-inch sheet saves you two makereadies and about $900 of press time. Your estimator knows this. The system does not. PrintSmith prices each SKU as a standalone job because its cost model is built around one job, one press, one imposition. So the estimator prices them separately, then manually discounts the total to a number that reflects the gang, and now the job costing baseline is fiction from the moment the quote goes out.

The same failure shows up on split shipments, on customer-supplied stock, on versioned work where 80 percent of the plate is common, and on anything where the cost driver is a decision made after the quote. Off-the-shelf MIS cannot fix this because the pricing engine is a fixed table of speeds and rates keyed to a job. Rebuilding it means rebuilding the product.

What a custom build does: model the estimate as a set of producible units, not jobs. An estimate references components, each with stock, ink, finishing ops, and quantity. A separate imposition planner takes any set of components and returns candidate press plans with real sheet counts, makeready counts, and waste. The estimator picks a plan, and the quote, the job ticket, and the cost baseline all derive from that same plan object. When the plan changes on the floor, the variance is visible against a real baseline instead of a guess. We build the speed and waste tables per press per stock category and seed them from two years of your own historical job data rather than vendor defaults. That single change is usually where the first release pays for itself: the shops we do this for routinely find they have been underpricing short-run coated work by 8 to 15 percent and overpricing long runs enough to lose bids they should have won.

Problem two: the real schedule is a whiteboard, and the whiteboard does not know about paper

Ask any plant manager where the schedule lives and you get an honest answer: the whiteboard, or a shared Google Sheet the CSRs are not allowed to touch. The scheduling module in the MIS is not used because it treats presses as generic capacity buckets and has no idea that the 40-inch Komori cannot run the 28-inch job, that the UV coater is down Thursday for a blanket change, or that the stock for job 41822 is sitting on a truck.

The result is the 4:30pm phone call. CSR promises a Friday delivery. Plant manager finds out Wednesday that the paper lands Thursday afternoon, bindery is stacked three deep, and the job needs to run on second shift or it misses. Someone eats overtime or someone eats a late delivery on an account worth $600k a year.

Off-the-shelf scheduling fails here because it is a Gantt view bolted onto an invoicing system. It has no constraint model. It cannot answer "if I take this job, what breaks."

What a custom build does: a constraint-aware scheduler where each press, coater, folder, cutter, and stitcher is a resource with real setup matrices (changing from 4-color to 6-color costs you X, changing stock caliper costs you Y), and where inbound stock receipts from your paper merchant feed the schedule as hard dependencies. The moment a PO from Veritiv or Lindenmeyr has a confirmed delivery date, every job depending on that stock reflects it. When a CSR opens a quote, the system shows the earliest honest ship date, and it shows it before the promise is made. AI helps in one specific place here: predicting makeready and run duration from your own job history, using stock, coverage, press, operator, and time of shift as inputs, trained on your press data rather than a vendor's defaults. In the shops we have had this running for six months, schedule adherence moves from roughly 70 percent to the high 80s, and that number decides your on-time delivery.

Problem three: job costing is theater because the data collection is theater

Every MIS sells shop-floor data collection. Every printer has a terminal at each press that pressmen are supposed to clock into. In practice, a pressman running a tight schedule clocks in at the start of a shift, forgets to clock the changeover, and clocks out at end of day. Your job costing shows an eight-hour job that took two. Or the terminal is 30 feet from the press and nobody walks over.

You cannot fix this with policy. We have watched three shops try, and every one of them gave up within a quarter. The behavior is rational: the pressman's job is to make good sheets, not to feed your reporting.

What a custom build does: stop asking humans for data you can take from the machine. Most modern presses expose JDF/JMF, and Heidelberg Prinect, Komori KP-Connect, and KBA systems all emit counts and state changes. Pull sheet counts, makeready start and end, and stop reasons directly. For older equipment, a $200 counter tap on the delivery gives you good-sheets and a timestamp. Then the terminal at the press asks the pressman exactly one question when something anomalous happens: "run stopped 22 minutes, why?" with four buttons. That is a two-second interaction, and pressmen actually do it. Now your job costing is real, your estimating tables self-correct from actuals, and your quarterly re-cost is automatic instead of a project nobody has time for.

Problem four: shipping is a separate universe from the job

Commercial print shipping is not e-commerce shipping. One job goes to four addresses in different quantities, on skids, some LTL, some UPS Ground, one hot box overnight, and the customer wants a packing list per drop that references their PO line items. ShipStation and the carrier tools are built for parcel. So your shipping clerk builds skid labels in Word, gets LTL quotes by calling a broker, and manually types tracking back into an email to the CSR. On a bad week that is 12 hours of a person's time and at least one drop that ships to the wrong address because a spreadsheet row got sorted.

Nothing off-the-shelf fixes this because the distribution plan needs to live inside the job record, and the job record lives in an MIS that thinks a job has one ship-to.

What a custom build does: distribution plans as first-class objects on the job. Quantity splits by destination, carrier rules per destination (LTL over 150 lbs, parcel under, customer-specified carrier honored), rate shopping across UPS, FedEx, and your LTL broker's API, and skid/carton labels plus BOLs generated from the plan. Tracking flows back automatically and fires a notification to the customer contact with the PO reference they need. Where AI earns its place: reading the customer's distribution list. Customers send these as PDFs, as Excel files with merged cells, as a paste in an email body, every one formatted differently. Document extraction turns that mess into a structured distribution plan in seconds with a human confirming edge cases. That is 20 minutes of retyping per job eliminated, and it removes the single most common shipping error we see.

Problem five: the customer wants status and you want to stop answering the phone

Your CSRs spend a meaningful share of their day answering "where is my job." Print MIS customer portals, where they exist, are ordering portals. They tell the customer the job was received. They do not tell the customer the job is on press right now and will ship at 6pm.

What a custom build does: the portal reads the same schedule and press telemetry your plant runs on. Job on press, 60 percent complete, in bindery, on the dock, tracking number. Proof approval lives there too, with the approval timestamp feeding the schedule so a late approval automatically repushes the ship date and tells the customer why. After-hours reorders on repeat SKUs go straight into the schedule from the last-run plan. That last one matters more than it sounds: a printer we built this for found roughly a fifth of reorder volume was coming in outside business hours from operations people who order when their own shift ends.

What this costs and how long it takes

These are Digital Heroes numbers from our delivery experience across 2,000+ projects, not industry averages.

A focused first release, which for a printer almost always means the estimating engine plus job ticket plus press schedule with real machine data, runs $60k to $130k and ships in 12 to 16 weeks. That scope earns its money on pricing accuracy alone and gets your estimators off Excel.

A full platform: estimating, scheduling, shop-floor capture, distribution and shipping, customer portal, and accounting integration, runs $150k to $400k phased over 6 to 12 months. We phase it because a printer cannot stop printing while you cut over.

What pushes you toward the top of the band in this category specifically: the number of distinct press and finishing configurations you have to model (a shop with sheetfed, digital, wide-format, and a bindery is three cost models, not one); JDF integration depth with Prinect or KP-Connect versus simple counter taps; multiple plants with real work-sharing between them; W2P storefront integration where orders arrive pre-configured out of Pageflex or EFI Digital StoreFront; and integrating with an ERP (Enterprise Resource Planning) or accounting system that is not QuickBooks. A shop with one press line and one plant lands near $60k. A three-plant operation with mixed sheetfed and digital, Prinect integration, and an existing Sage install lands near the top.

What keeps it down: starting with estimating and scheduling only, and living with your existing MIS for invoicing for the first year. Most shops do not need to replace the invoicing system. They need to stop pricing blind.

Build versus buy: take the off-the-shelf tool seriously first

PrintSmith Vision is fine for a single-plant shop doing straightforward sheetfed and digital work under roughly 150 jobs a week, where the estimator can hold the exceptions in his head. Printavo is good for smaller shops that mostly want quote-to-invoice flow without a plant scheduling problem. If that is you, building is a waste of $100k. Buy, configure it properly, and put the money into a press.

The signals it is time to build, and I mean these literally:

Your estimator maintains a private spreadsheet that overrides the system, and if he left tomorrow you could not quote accurately. Your real press schedule is not in the MIS. Your job costing reports are ignored in management meetings because everyone knows the labor data is garbage. You are turning down or losing gang-run and versioned work because you cannot price it fast enough. You have added a second plant and the two of them cannot see each other's capacity. Any two of those, and the off-the-shelf tool is no longer a system, it is a filing cabinet you pay a subscription for.

The MIS vendors are not going to fix estimating for you. The fix requires modeling your specific presses, your specific stocks, and your specific way of selling. That is not a product. That is your business.

How to choose a developer for printing company software

Ask them to model a gang run in front of you. Not a demo, a whiteboard. If they cannot explain how one press sheet carries components from three different jobs with different quantities and how cost gets allocated back, they have never built this. This is the single fastest filter.

Ask what they will do about shop-floor data. A developer who says "we will build a nice clocking UI and train the pressmen" has not been on a press floor at 2am. The right answer involves JDF/JMF, counter taps, and asking humans as little as possible.

Ask about the paper supply dependency. If the schedule does not consume inbound stock receipts, it is a Gantt chart, not a schedule. A developer who has done this will ask you who your merchants are and whether you get confirmed delivery dates or estimates.

Ask who owns the code and where it runs. You should own the repository outright, on your organization's account, from day one. If you print anything with PII or protected health information, direct mail for healthcare payers or financial statements, ask specifically about data handling, access logging, and whether they have shipped under a customer BAA or SOC 2 obligation before. A lot of print work is quietly regulated and the developer needs to know that before they design the database, not after.