Paper Delay

“What did you learn?” I asked.

“I drew the picture of our Customer Experience system,” Sean explained. “I didn’t realize it was really a system. I drew the picture in detail to capture all the places the Service Ticket sits, and indicated whether is was a Paper Service Ticket or if it had been converted to an Electronic Service Ticket.”

“Why did you do that?”

“I was thinking, the Customer Service Rep is connected to the Service Ticket server, so they can look things up. But, for security, they are blocked out from writing service tickets. That function is relegated to Ops, who really doesn’t have the time for all this.”

“What’s the security issue?” I wanted to know.

“Ops is afraid that if the CSR writes up the ticket, they will make a mistake and route the ticket to the wrong place.”

“What do you propose?”

“I want to allow the CSR to write up the ticket while the customer is still on the phone, no more paper,” Sean started. “I want to program a drop down box with only four reason codes available plus a code for needs supervisor review. If that ticket goes straight to resolution as an Electronic Service Ticket, that takes three, maybe four days of delay out of the system.”

“How are you going to explain your proposal so you can get buy-in and approval for the change?” I asked.

Sean grinned. “I am going to lead with – Every time something is written on a piece of paper, it introduces delay into the system.”

One thought on “Paper Delay

  1. Micah W

    Good solution! Seeing tasks and people interactions as components of systems is a powerful perspective. It highlights stakeholder needs/interests in the current system and makes it almost easy to address them in the new proposal

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.