“What do you mean by ‘reset’?”
That question stopped our December 2024 pilot review. I had just marked “Kyocera reset PASSED” next to a DuraForce phone, and Jackie, one of our operations leads, put her pen down.
“When you say reset,” she asked, “do you mean clearing user data? Re-enrolling the device? Wiping the profile so IT can apply a fresh setup? Or all three?”
I didn’t have a clean answer. And for someone who spends their working life reviewing quality standards and acceptance criteria, that was a little humbling.
Why we were looking at Kyocera at all
I wear the quality hat for a field services company. Most of my day involves checking deliverables before they reach customers. But every year, I also get pulled into the internal review that happens before we update our office equipment. In early 2024, that review turned into a much larger project.
We were approaching the end of a printing contract, and we had a separate headache: field staff phones. The old batch of rugged phones was aging out, and the replacement cost was higher than anyone wanted. Someone in procurement asked whether we could consolidate. Instead of buying printers from one vendor and phones from another, why not look for a supplier that could support both?
That’s when Kyocera showed up on our radar. They offered to walk us through a pilot that included a few office multifunction printers and some Kyocera cell phones. To be honest, I was skeptical at first. I had seen too many “integrated solutions” that were just a sales pitch. But the pilot was structured well, so we agreed to run it.
Who is Reid? Who is Jackie?
Those two names matter more than any device spec in this story.
Reid was the Kyocera technical contact assigned to our trial. I called him our “glue guy,” because his real job was to help us understand where the hardware ended and where our own processes had to take over. He was the one who showed us how print authentication should work on the TASKalfa units. He also sat through our phone configuration meetings without making us feel silly for asking basic questions.
Jackie worked on our side of the table. She runs operational reporting, and she has a habit of asking the question nobody wants to hear. She was the one who pushed back when I called the reset test “complete.” She wanted to know what reset meant to a technician in the field, what it meant to IT, and what it meant to the device itself.
Later, when people in our office joked about “who is Reid” or “why is Jackie in every meeting,” the answer was simple: they were the people who kept us from signing off on a test that looked good but didn’t reflect our real workplace.
Phase one: printers
The printer side of the pilot ran pretty smoothly. We tested two TASKalfa models and one ECOSYS model over the course of about three weeks. Our staff printed standard office documents, some double-sided jobs, and a few larger sets. We checked scan-to-folder, scan-to-email, and the authentication setup that ties print jobs to a user ID.
The Kyocera machines handled the workload without any jams. Color registration was consistent, and the admin interface was clear enough for our IT team to configure without a treasure map. I included that in the pilot notes. But I also added a line that was more about us than about the hardware: we had to update our own print driver packaging because the old drivers were still pointing to a retired print server.
That should have been my first clue. The hardware wasn’t the problem. Our surrounding process was.
Phase two: Kyocera cell phones and voicemail setup
The second phase involved a handful of DuraForce EX phones. We weren’t expecting luxury devices. We wanted something that could survive a drop out of a truck and still connect to Wi-Fi calling in a warehouse. Kyocera cell phones have a reputation for durability, so they made sense as a candidate.
We started the phone pilot with the basics. We inserted SIM cards, joined the devices to our mobile device management platform, and tested the network connections. One of the tasks was straightforward: how to set voicemail on the phone. I remember dialing into the voicemail service, setting a temporary PIN, recording a greeting, and then calling back to confirm it worked. It took a few minutes. No drama.
Then we moved on to the harder part. We needed to know what happened when a phone reached the end of its first assignment.
Where my assumption fell apart
In the original spec I wrote for the pilot, I had included the phrase “must support factory reset.” That sounds harmless. But I never defined what a successful reset looked like.
I assumed factory reset simply meant wiping the phone and returning it to like-new condition. In my mind, the next user would turn it on, connect to Wi-Fi, sign in, and the MDM system would take over. That’s how it worked with the first batch of new phones. They came out of the box, joined the network, and everything flowed from there.
What I didn’t account for was device lifecycle state.
When we reset one of the Kyocera DuraForce phones and tried to re-enroll it, the phone didn’t behave like a brand-new unit. It took longer to appear in the MDM console, and the policy assignment didn’t apply automatically. A technician had to manually correct the device record before the phone picked up the right Wi-Fi certificates. That single issue cost us a few hours of back-and-forth.
My first reaction was to blame the hardware. Reid called me on it, politely. He pointed out that the phone had performed the reset correctly. The problem was our enrollment workflow. We had built a process that assumed every device entering the MDM was new. We never considered a scenario where a phone was being reassigned after a previous life.
In other words, the Kyocera reset process worked the way it was supposed to. Our own logic was the bottleneck.
The lesson about reset and redeployment
Here is a more honest way to describe what happened. We didn’t have a reset problem. We had a definition problem.
When an IT technician hears “reset,” they often think about the physical act of wiping the device. When a service manager hears it, they think about returning the phone to a useful state for the next person. When a quality person hears it, they should think about acceptance criteria. What does the device need to do after the reset? Does it need to reach a clean state? Does it need to be in the correct MDM group? Does it need to pass a voicemail setup test? Does it need to register with the correct Wi-Fi certificate?
For us, the last two points were the ones that mattered. A phone can be wiped successfully and still fail if the certificate profile is missing. It can be reset and still cause an hour of frustration for someone who just needs to set up their voicemail and get back to work.
Once we clarified that, the whole project changed direction. We stopped focusing so much on “is this phone tough enough” and started asking “can we manage this phone through its whole life?” The second question is harder, but it’s also the reason we decided to move forward.
Why we chose Kyocera eventually
I want to be careful here. This is not a story about Kyocera being perfect. The printer side of the pilot had its own little issues, and the phone setup required cooperation from multiple teams. No vendor can fix a messy internal process.
But the pilot did change my perspective. I used to evaluate office equipment the way I might compare specifications on a parts list. Does it meet the speed requirement? Does it support the right security protocol? Does it fit the budget?
Those questions still matter. But they miss the larger point. A Kyocera cell phone can survive a two-meter drop and still be useless if a technician can’t get it configured in less than an hour. A printer can print beautifully and still cause daily pain if the authentication flow doesn’t match the way people actually work.
The reason we chose Kyocera came down to the way Reid and Jackie helped us see that gap. Reid shared the technical details we needed, but he also helped us understand where our own workflow had to adapt. Jackie made sure we tracked the full lifecycle cost, not just the hardware price.
After the pilot, we rewrote our deployment checklist. The new version includes language around device reassignment, clean provisioning, and acceptance testing after a reset. We added a line that says any returned phone must be able to re-enroll without manual database edits. We also added a quick “how to set voicemail on the phone” step to the user onboarding guide, because something that looks obvious to a technician might not be obvious to a new hire in a warehouse.
A better definition of quality
I am still the person who checks the details before something goes out the door. That hasn’t changed. But this project made me rethink where real quality comes from.
Hardware reliability is part of it. Kyocera products felt solid. The printers held up through a heavy test volume, and the DuraForce phones handled the drop tests we ran. I don’t think I could write a review like this if the equipment had failed constantly.
The bigger opportunity, though, is in the process around the hardware. A reset is not a button. Voicemail setup is not just a feature to check off. Device lifecycle management is where good hardware either succeeds or gets blamed for problems that were never about hardware.
Now when someone asks me who Reid was in that project, I don’t tell them his job title. I tell them he was the person who asked us what we meant by reset. And Jackie was the person who made sure we didn’t leave the meeting until we had an answer.
That pilot turned out to be less about Kyocera and more about us. We went in looking for office equipment. We came out with a better way of defining what a deployable device looks like in a modern workplace. That’s the kind of quality that doesn’t show up on a spec sheet.
Leave a Reply