Is the Responsive Web a Mobile App Killer? Pt 2

Printers themselves transcend industry verticals. Sure, some businesses use them more than others. Sure, the paperless office is a thing, although more in our collective imagination than reality. Printer consumables and maintenance are big markets. Even better, they are big recurring revenue markets. 

Best of all, they're recurring high-margin markets.

Everybody prints.

Everybody in the IT field wants a bigger piece of that pie. My friend wants the whole darned pie. Who can blame him? 

Just in the Montreal area, I figure there are likely upwards of 37,000 office printers (74 million square feet of office space. One printer per 2,000 square feet...close enuff). That represents a very conservative $6,000,000+ of potential monthly sales just from one marketplace!

The Value Proposition: Customer Side

We already see why PrinterPeeps should exist from the service provider's view. Why should customers care?

Originally, I thought PrinterPeeps should work on a per-copy basis. By that, I mean that customers pay X cents per copy and PrinterPeeps handles the rest except for the paper. 

That opens too many cans of worms. 

That model would mean two things. One, every printer would need to be brought up to snuff before the system could start. That is a barrier to entry that is unacceptable from both the customer and PrinterPeeps' side. Two, given that barrier, some printers in a location would be covered while others were not. 

There can be no barriers to entry. PrinterPeeps should build the best path to printer consumables business. That means a pay-as-you-play system.

Junior level Printer Techs would visit offices to conduct visual examinations, run a test print, and perform any required cleaning. While there, they count cartridges in inventory and top up as required. Here, we will take a hint from Amazon. Those consumables will never be much more expensive than anywhere else. 

They then take note of the internal copy counter. 

The pitch is simple. We will come in and check your printers regularly. We will do the regular maintenance. We will do the regular internal cleaning. We will make sure you never run out of consumables. All you need to do is buy the consumables from us at the price you're paying now. 

We'll even do the first visit right now.

How many of you would sign up?

I know I would.

To make it work at a profit

That's the catch, ain't it? Adding services while not adding to pricing seems self-defeating. 

No, it's not easy. If it was easy, my friend would have done this years ago.

It's not impossible either. The trick is in building the service with an extreme (maybe even insane) level of efficiency. It must also be completely scalable. It should work as easily here in Montreal as in Toronto, Vancouver, New York,  London, or Kalamazoo (I love that name).

Device Agnostic: Whatever system we use must work equally well on phones (whether iOS, Android, Windows, or whatever comes along later), phablets, and tablets. We will use the employees' devices (BYOD). It's much cheaper to pay for a data plan than pay for a phone and a full-service plan.

Managing the Middle Line: This would be an add-on venture. There should be little or no additional fixed costs to the parent company. That said, there would be some internal policy stuff to handle to meld the new venture to the existing one. The most obvious point is "ownership" of the base customers. We won't bother with that here.

The wheel already exists: Let's not reinvent it. We should use existing APIs whenever and wherever possible.

Maximizing customer-facing time: We can't earn profits while in transit between customer locations. Industry verticals are out of the question. Geographical territories are a must. So is a route-optimizing function. Supporting APIs: Canada Post Housholder counts, Google Maps

Minimize human resources costs: We can't use senior techs. That would be far too expensive. Juniors, on the other hand, could become expensive because they lack planning/scheduling experience. The system would need to auto-generate call lists and sales lists while calculating a minimum transit time. Supporting APIs: Google Maps, Fusion Tables, UPS, Fedex.

Minimizing off-book time: We can't have techs returning to base too often. Let's take another page from Amazon and embrace multiple bases, or start points if you prefer. Each tech will start from their home. 

The system will pull a call list, rank points of call by distance, and list them in optimal order (Google Maps API)

An arrangement with a courier company will collect used parts, if any, and replenish them. Techs will start every day ready to go, call list in hand (well, on-device anyway). The system will need to track parts as they are used and auto-generate replenish orders. If there aren't any, it should not call the courier company. Any required parts not in regular truck stock must also be ordered. Those special parts will need special treatment.

Any non-truck stock item needed will be automatically ordered. The customer call will not be rescheduled until a tracking number is generated and delivery is confirmed. Then it will be scheduled immediately. Tech will get a text when it is delivered. Supporting APIs: UPS, Fedex, SMS (texting) service, possibly the courier company's API.

Speeding up inventory counting: The time spent at each customer should be minimized. I'm really not sure if we should use the phones' bar code/QR code scanning ability or not. If this was a real company, some testing would be in order. Let's just forget about this for now.

Error avoidance: Call-backs are a waste of time. So is trying to figure out where stuff is. The phones' GPS can help with the latter. The former can be avoided by having the system update the customer file and monitor the GPS. So, when I clean the printer, I click on a clean complete button. When I count inventory, it updates the customer file and places an order.

If the GPS location changes before both are done, the phone vibrates and a gets a warning message which also updates the system.

For future efficiency upgrades, elapsed time at a location is added to the DB. Should we use the phones' camera to upload pictures of test prints for possible future comparisons? Why not?

Closing thoughts

Okay, so this isn't a formal Business Plan. It's not even close. It's just a basic scope of work to build a sample Responsive Web app. I just want to give an example of just how easily the Responsive Web can pull mobility out of a strictly Marketing role into an Operations and Sales role.

Now it's your turn. Everybody who reads this is now "officially" on fictitious PrinterPeep's fictitious board of directors and get a seat at our really big fictitious boardroom table. Don't get too excited. It's not like it's a paid position. Maybe we can pay you fictitious dollars from our fictitious bank accounts funded by our fictitious sales. 

Maybe not.

So, all you new board members, any ideas on what else is needed/wanted? Let's talk this through before I build the mock-up.

Let's remember that it will be a mock-up, not a real thing. For example, I already see that downtown core territories will need different treatment. I don't know how your downtown is, but there's no way I would want to bring a truck to downtown Montreal if I can help it. Parking and tickets would wipe out profits. Let's forget about that too for now.

Cheers