Category: Business

Reducing Customer Service Calls Wait Time

As we finally managed to get through the Chase IVR only to be told that the expected wait time is ten minutes … in addition to the eight minutes we’ve already spent trying to convince their IVR that we didn’t need to pay our bill or check out balance, I wonder how feasible it would be to drop the caller into the CS rep queue when the call is first answered, let them spend some of their hold time telling the IVR what exactly they need (possibly moving their placeholder to another queue if, say, they seem to want tech support and not general CS), and either deleting the placeholder because the caller’s problem actually got resolved by the computer or adding a “ready to talk” attribute to the placeholder so the call is ready to transfer out to the next available agent. Bummer that I haven’t done IVR call route development in decades because I’d love to prototype that logic and see if it actually works (it’s possible we’d just end up with hundreds of pointers to people who are still navigating the IVR instead of actually reducing wait times).

The hazard of curbside pickup

I’ve had an ongoing problem with the curbside grocery pickup — it’s a great time saver (and basically eliminates off-list purchasing / impulse shopping), and I get the limitations of asking someone else to think for you (I add a note that indicates the exact number of large/small *bunches* of bananas I actually want whilst ordering unit “1” banana, and I know they are not just going to figure it out and get jicama when they’re out of celery root). My problem is that the quality of the food that ends up in my order is absolutely not something I’d have bought. I won’t buy mushy, rotten oranges. Or visibly moldy strawberries. Or meat with huge chunks of fat. I’ve taken to putting in a big order of shelf-stable staples for pickup a few times a year and selecting the perishables myself. And accepting the time / quality trade-off when I ask them to select my produce for me.

Thought that was a problem unique to the grocery store, but we picked up chicken chow from Tractor Supply today. Last time, the 6 pound bag that was brought out instead of a 40 pound bag was really obvious. And quickly corrected. This time? We bought two bags of food — the first one was fine. Upon lifting the first bag out of the car, though, I discovered the second bag. A bag which looks like it was dragged across the warehouse floor and then taped up to retain whatever was left in the bag. This certainly isn’t a bag someone would have put into their cart at full price. I’ve seen other companies slap a discount sticker on a mostly full taped up bag. Unloading the ripped bag of something close to 40 pounds of chicken food, at full price, on a curbside pickup? Kinda sucky!

Luckily, Tractor Supply has excellent customer service policies. I used the ‘contact us’ form to tell them about the problem — and, yeah, I could have just brought it back to the store. But … had I been in the car park when I noticed the bag, I certainly would have asked for the bag to be swapped out. A couple extra minutes was worth it to avoid whatever contaminants got into the bag and whatever amount of food fell out of the bag. Half an hour of driving? Not worth it for what’s probably some warehouse dirt and maybe a pound of missing food. Within a few hours, a customer service rep rang be to apologize for the mangled bag. He refunded the purchase price and issued a gift card for our inconvenience. That’s more than fair.

Better Business Bureau

There are a few scenarios where the advertised protection a process offers are effectively worthless — Ebay disputes won’t refund shipping charges or require you to pay additional shipping to return an item, so shorting the customer by less than the shipping cost makes winning your dispute worthless. The 1970’s Fair Credit Billing Act gives you the right to dispute charges up to 60 days after the charge — but, when I ordered a CSA membership in September that started the following March … that window precluded a simple charge-back when the CSA claimed I was not on their list. I expect this window is why people get upset when companies finalize the charge before shipping the product.

Outside of the FCBA contest period, there’s not a whole lot you can do. Small claims could be a route, but that is less effective for inter-state transactions. Some company in Texas doesn’t really care that they’ve got a judgement against them in Ohio. Ohio doesn’t have a lot of power to force payment, either. Traveling to the state with more direct jurisdiction is expensive, and you’re not likely to reclaim damages incurred in obtaining the judgement (i.e. the settlement is not apt to cover your hundred dollar refund, three hundred dollar plane ticket, thousand dollars in hotel charges, and couple hundred bucks for a rental car).

That’s where we were with Keg Factory. We’d gotten a DigiBoil with an inaccurate temp reading. And been told by KegLand, the manufacturer, that the unit isn’t meant for mashing so isn’t designed to have an accurate temperature reading. (Asking why there’s a mashing kit for the not designed for mashing product didn’t yield any illuminating answer) … the owner of Keg Factory told us the product didn’t seem to be a good match for our needs (true, but the advertised function of the product certainly met our requirements!) and offered a shipping label to return the thing. Seemed like a good idea to stop wasting time on a product if the manufacturer says it’s not good enough for its intended purpose. We confirmed they weren’t looking to add a restocking fee or otherwise charge us — a full refund was what was on offer. Yup, that’s it. So we packed up the thing, shipped it off, and confirmed delivery. That was March. We proceeded to contact them looking for our refund. Calls routed to voicemail. No return e-mails. Online chat where we’re the next in queue for hours. When we did get through to someone, we’d be told someone would look at it that day. And still no refund.

As a last ditch effort, we filed a complaint with the Better Business Bureau. The Austin office concurred that our problem fell into their purview and forwarded the complaint on to the vendor. We got a refund notice within a few hours! It took a few days for the refund to clear through to my credit card, but a complaint with the BBB accomplished in three or four days (days where we didn’t do anything) than months of calls / online chats / e-mails managed. Sad that it seems to take publication of poor service to correct a problem … but I’m exceptionally glad to have this saga over.

Air Popper

We got a air popper to make popcorn (we’d made some really good caramel corn a few night previously, and really want to make some more … plus it’s just easier to use an air popper than to pop the kernels on the stove). Picked Presto’s 04820 (which is cheaper and , evidently, the same as the 04821 but without the popcorn company’s logo on it) – a 1475 Watt air popper). It works well,  but there’s a strange design decision — no on/off switch. Obviously, we can unplug the thing and plug it in again when we’re ready to use it. I expect a majority of the use cases involve the popper being put into a cupboard somewhere when not in use anyway — so the machine is going to be unplugged after each use.

I expect this is a trend we’ll see in small appliances — it’s a component cost the company saved, reduced assembly time, and a point of failure is eliminated.

Simplified Outage Reporting

We’ve lost power the past few days — I think that’s because the forestry crew is clearing a few trees that are down on the power lines, but I don’t know so we report the outage. First Energy has a really cool way of reporting outages — you use SMS to register your phone with your account. Once the phone is registered to an account, you can text “OUT” to their short code. There’s a short code to register for outage notifications, status alerts. So when the power went out today, it took about three seconds to report the outage. No walking through the IVR to report the outage online. I hope to see more companies doing this in the future.

Cloudy ROI

I often have trouble seeing the value behind cloud offerings — but most cloud migrations I’ve seen have done 1:1 replacement of locally hosted servers with cloud hosted servers. The first two years, the cloud hosted servers are cheaper (although that’s some dodgy accounting as we’re assuming no workforce changes as a result of outsourcing servers and depreciation of the owned asset is not considered). The third year, though, is a break-even point. General Depreciation System considers computers a five-year property, but there are accounting practices to handle fully depreciated assets. It remains on the balance sheet as a cost, it’s accumulated depreciation is listed as a accumulated depreciation contra asset item. When you *do* stop using the asset, the accumulated depreciation account is debited for the full depreciated amount, the fixed asset account is credited with its full cost. Point being I can continue using a computer asset after five years. Cloud hosted servers make financial sense for a company that tends towards “bleeding edge” implementations (buying the new whatever next year), but for a company that buys a server or application and then uses it for a decade … you’re simply turning capital expense into a greater ongoing operating expense. Which … good this year, but bad in the long term.

Now for a smaller company that doesn’t have a dedicated IT department, and that doesn’t actually need the capacity provided by a single modern server … externally hosting resources is financially beneficial. A web site, e-mail, chat-based customer service? All make sense to host externally. You don’t have to own half a dozen servers, make sure they’re backed up, etc. But I don’t see the cost benefit at enterprise levels unless (1) you want to build data centers close to customers without the expense of actually building a data center. For instance, opening your services to customers in the EU … getting a data center set up in, say, Germany isn’t a quick proposition. As your business grows, it may become “worth it” to invest money into a European data center. But cloud-hosted computers from some major provider who already has a presence there provides quick time-to-market and minimizes up-front cost. Some countries may have a laborious process for prospective businesses too — a process the cloud hosting provider has already navigated. Or you (2) plan a substantial workforce reduction. If someone else is backing up, patching, and monitoring systems … you don’t need people performing those duties. Since a cloud-hosting provider is able to leverage those employees across far more servers than you’d need — there’s a place where scale produces a cost benefit. But, strangely, I don’t see companies reducing IT operations staff after moving to the cloud. This may be a long-term goal to ensure the enthusiasm of staff for the move — it’s not particularly enticing to put six months of work into a project that ensures my job goes away. Or this may just be a thing — move to the cloud and still have twenty ops employees.

Agile Methodology Is Not Anarchy

For the past several years, my employer has been moving toward an Agile development methodology. There are some challenges when mapping this methodology into operations because it’s not the same thing; but, surprisingly, those are not where I have experienced challenges. The biggest challenge during this transition is some of my coworkers seem to think the methodology is that there are no rules.

A friend of mine, a fairly eccentric history professor, used to say that a little knowledge is a dangerous thing but you’ve got to emphasize LITTLE. And it seems like we’re encountering a situation where Phil’s emphasis holds true: the only thing garnered from from Agile training is that the documentation and process from waterfall projects are no more. But breaking away from the large-scale view of a P.R.O.J.E.C.T. for Agile development is a bit like breaking a monolithic application out into microservices — it still needs to do all of the same ‘stuff’, it just does it differently. And there are still policies and procedures — even a microservice team is going to have a coding standard, a process for handling merges, a way of scheduling time off, and some basic idea of what their application needs to accomplish. Sure, the app’s design will change incrementally over time. But it’s not an emergent property like chaos/complexity theory.

Maybe the “what Agile means to me” mentality comes from failing to clearly map a development methodology into an operations framework. Maybe it’s just a good excuse to avoid components of work that they do not enjoy. To avoid “agile operations” becoming “no boring planning stuff!!!”, I’ve outlined ways in which the Scrum methodologies the company wishes to adopt can be used to streamline operations. It helps that our group is reorganizing into an operational/support group and an architecture/design group — I see a lot of places within the operations team where Scrum approaches make sense.

Backlog — prioritizing the ticket queue like a backlog and having support staff constantly pulling from the top of the list — not only is this an awesome way to avoid the guy who scans the queue for the easy jobs, but it ensures the most important problems are being resolved first. A universal set of stakeholders does not exist for the ticket queue — someone whose ticket is ranked fifteenth on the list may disagree, and they are welcome to add details explaining why the issue is more impacting that it seems on its face. But 90% or more of our tickets are “Sev3” — which basically means both “we want it done ASAP” and “it isn’t a wide-spread high impact outage”. Realistically, dozens of tickets do not have the exact same time constraint and impact. There is extra work for management in converting a ticket bucket into an ordered backlog, but the payoff is that tickets are resolved in an order that correlates to the importance of the issue. In addition to the ticket queue, routine maintenance tasks will be included in the backlog. And prioritized accordingly.

Very short sprints — while developers moving from Waterfall to Agile might start from a month (or two) long sprint and trim weeks as they evolve into the process, operations starts from the other end of the spectrum. Our norm is to grab a ticket, sort it, then look at the queue and grab another one. We are planning for hours, maybe a day or two. This means we might establish application access on Tuesday that isn’t needed until next Monday. Establish a sprint that lasts a week, and use the backlog to get tickets that have lower priority (either because the impact is lower or because resolution is not needed for a week) included in the sprint. Service interruptions, SEV1 and SEV2 tickets, will occur and should be assumed in the sprint planning (i.e. either take enough work that you think it will just get done with no service interruption tickets and accept that some tickets from the sprint will be incomplete or leave some space for service interruption tickets and have staff pull “bonus” tickets from the top of the backlog if they have no work toward the end of the sprint).

Estimation — going through the tickets and classifying each incident as a quick little task, something that will take a few hours, or a significant undertaking facilitates in sprint planning. It’s difficult to know how many tickets I can reasonably expect to include in a sprint if I cannot differentiate between a three minute config change and a three day application rollout.

Multi-tasking — Implementation, support, and ticket resolution tasks are no longer a big bucket of work that individuals attempt to multi-task to complete. There are distinct tasks that are completed in series. Some tickets require information from the user; put the ticket on hold until a response is received and move on to the next unit of work.

Velocity — historic data based on time estimates cannot be generated, but simple number of tickets per week pre- and post- can certainly be compared. And going forward, ticket counts can be weighted by estimation values.

Stand-ups are a bit of a mental sticking point for me. I can conceive the value of spending a few minutes reviewing what you’ve done, what you plan on doing, and ensuring there is a ready forum to discuss any sticking points (maybe someone else has encountered a similar situation and can offer assistance). Stand-ups could include a quick discussion of any priority shifts (escalations, service interruptions) too. *But* my experience with stand-ups has been the attendance test variety — stand-ups that were used to hurt individuals who didn’t make it to the office by 08:00. Or those who weren’t around at 16:50. I don’t think it’s reasonable to ask someone who got into an issue and worked until 7P to show up at 8A the next day. I also don’t think it is reasonable to expect someone who came in at 6A to continue working until 5P. Were a stand-up scheduled in the middle of the day, I might feel differently about them.

DevOps Alternatives

While many people involved in the tech industry have a wide range of experience in technologies and are interested in expanding the breadth of that knowledge, they do not have the depth of knowledge that a dedicated Unix support person, a dedicated Oracle DBA, a dedicated SAN engineer person has. How much time can a development team reasonably dedicate to expanding the depth of their developer’s knowledge? Is a developer’s time well spent troubleshooting user issues? That’s something that makes the DevOps methodology a bit confusing to me. Most developers I know … while they may complain (loudly) about unresponsive operational support teams, about poor user support troubleshooting skills … they don’t want to spend half of their day diagnosing server issues and walking users through basic how-to’s.

The DevOps methodology reminds me a lot of GTE Wireline’s desktop and server support structure. Individual verticals had their own desktop support workforce. Groups with their own desktop support engineer didn’t share a desktop support person with 1,500 other employees in the region. Their tickets didn’t sit in a queue whilst the desktop tech sorted issues for three other groups. Their desktop support tech fixed problems for their group of 100 people. This meant problems were generally resolved quickly, and some money was saved in reduced downtime. *But* it wasn’t like downtime avoidance funded the tech’s salary. The business, and the department, decided to spend money for rapid problem resolution. Some groups didn’t want to spend money on dedicated desktop support, and they relied on corporate IT. Hell, the techs employed by individual business units relied on corporate IT for escalation support. I’ve seen server support managed the same way — the call center employed techs to manage the IVR and telephony system. The IVR is malfunctioning, you don’t put a ticket in a queue with the Unix support group and wait. You get the call center technologies support person to look at it NOW. The added advantage of working closely with a specific group is that you got to know how they worked, and could recommend and customize technologies based on their specific needs. An IM platform that allowed supervisors and resource management teams to initiate messages and call center reps to respond to messages. System usage reporting to ensure individuals were online and working during their prescribed times.

Thing is, the “proof” I see offered is how quickly new code can be deployed using DevOps methodologies. Comparing time-to-market for automated builds, testing, and deployment to manual processes in no way substantiates that DevOps is a highly efficient way to go about development. It shows me that automated processes that don’t involve waiting for someone to get around to doing it are quick, efficient, and generally reduce errors. Could similar efficiency be gained by having operation teams adopt automated processes?

Thing is, there was a down-side to having the major accounts technical support team in PA employ a desktop support technician. The major accounts technical support did not have broken computers forty hours a week. But they wanted someone available from … well, I think it was like 6AM to 10PM and they employed a handful of part time techs, but point remains they paid someone to sit around and wait for a computer to break. Their techs tended to be younger people going to school for IT. One sales pitch of the position, beyond on-the-job experience was that you could use your free time to study. Company saw it as an investment – we get a loyal employee with a B.S. in IT who moved into other orgs, college kid gets some resume-building experience, a chance to network with other support teams, and a LOT of study time that the local fast food joint didn’t offer. The access design engineering department hired a desktop tech who knew the Unix-based proprietary graphic workstations they used within the group. She also maintained their access design engineering servers. She was busier than the major accounts support techs, but even with server and desktop support she had technical development time.

Within the IT org, we had desktop support people who were nearly maxed out. By design — otherwise we were paying someone to sit around and do nothing. Pretty much the same methodology that went into staffing the call center — we might only expect two calls overnight, but we’d still employ two people to staff the phones between 10P and 6A *just* so we could say we had a 24×7 tech support line. During the day? We certainly wouldn’t hire two hundred people to handle one hundred’s worth of calls. Wouldn’t operations teams be quicker to turn around requests if they were massively overstaffed?

As a pure reporting change, where you’ve got developers and operations people who just report through the same structure to ensure priorities and goals align … reasonable. Not cost effective, but it’s a valid business decision. In a way, though, DevOps as a vogue ideology is the impetus behind financial decisions (just hire more people) and methodology changes (automate it!) that would likely have similar efficacy if implemented in silo’d verticals.

 

Sitting is the New Smoking

Some company official posted an internal article titled “Sitting is the New Smoking” to tell us all how bad sitting for prolonged periods of time can be for your health. While they make suggestions for using your break to do some exercises or suggest cube-exercises … frankly, they’ve designed a job that requires sitting for prolonged periods of time.

Some people have standing desks. Not all. Not most. My understanding is these things were purchased as accommodative equipment the company had to purchase based on medical need. If sitting is as bad for your health as smoking, did the company not just publish its own statement of medical need to support widespread purchase of standing desks?

Beyond near-term costs, though, the assertion brought to mind the Black Lung Benefits Act from nearly two decades ago. While mine operators may have been able to reduce exposure to coal dust, some level of exposure to coal is requisite in mining the stuff. A generally unavoidable environment based on the work being done caused a major medical problem that led to disability and death, and companies ended up shelling out disability payments and survivor benefits. It wasn’t quite the least they could possibly do to quell public outcry, but there are a lot of *’s on qualifying that let reasonable requests be denied or pushed off for years without retroactive payments. Even so, the payout is like eight grand a year per afflicted miner. And there are like 30k recipients (and something like 5k dependents, which can drastically increase the annual payout). That’s minimum two hundred forty million bucks in 2017. And it’s a LOT less now than a decade ago. There are nuances to determining the payer, but it is generally the mine operator most recently employing an affected individual. A significant portion of this money has been payed by mine operators.

Sitting at work is different from exposure to coal whilst mining coal. There’s no reason most jobs require sitting for hours on end. Historically there’s a component of elitism — a hundred plus years ago, low paying jobs were physically intensive, and it was a bit of an elite thing to be able to sit at work. Now the sign of affluence is a few spare hours a week to exercise, and sitting is just a norm no one has sought to change. If a company is aware of how bad sitting is for its employees, seems like said company would have a better defense against liability if they actively attempt to re-design their workplaces and jobs to avoid sitting. Sending out a mass mail telling you how bad something is or having a webinar to tell you how bad it is … but generally employing people to sit for hours at a time isn’t much in the way of due diligence. Routinely deploying standing desks, even in training classrooms, would reduce mandatory sitting among call centre staff. Walking meetings for one-on-one or small group sessions.

 

What, me worry?

Steven Mnuchin, one of Trump’s best people, is not worried about mass worker displacement due to automation. Said so at an event hosted by Axios. I’d love some of whatever he’s been toking.

In the near term (and evidently that’s all business execs or government types care about these days), sure automation and AI will drastically increase profitability. But I foresee the trend following a similar path as off shoring … great for individual businesses, but at some point capitalism mandates people have some money to buy the stuff and neither offshoring or wide-scale automation is sustainable. Offshoring at least provided alternate jobs for enough people to float enough debt to sustain the market near-term. We’ve got “knowledge workers”. But what percentage of those can be turned into AI programs? A significant number. I automate 80% of IT work. Chat bots could provide at least half of legal and medical consultations — the routine stuff. Robots make products, load the truck/train/drone that drives itself. Right to your door, or even inside if you have the Amazon lock. There aren’t a lot of jobs where some portion couldn’t be automated today. And budget cuts and productivity demands essentially require it. Some lucky few own doomed companies and profit for some time, another really lucky few are AI programmers and electronics engineers (although self-building AI/robots are totally a thing too). Maybe automation will beget a whole new industry that will provide good jobs for billions of people. Maybe the capitalist system will collapse and everyone will have more than they need (the Star Trek series, I guess). But I don’t know that I wouldn’t worry about the impact automation has on employment and the economy.