I spend a few days in the support trenches now and then to see what our agents were commonly facing when dealing with clients. One such day, it became apparent that most calls were investigating credit card charges since we're a SaaS that powers many sites. Watching the CSRs navigate through an ugly and slow transaction search screen made it painfully obvious we need to re-tool that for them. Within days we had a much faster db query and more flexible search parameters that helped them quickly find transactions. I'd often poll the CSRs for new feature requests and look for common threads. A small % increase in efficiency over many reps adds up to alot of $$$s saved and customer satisfaction.
I worked in a callcenter doing software/dev stuff, and would sometimes talk to the folks handling calls. I got in trouble for this, because they were supposed to talk to their manager for requests and such, and I'd occasionally fix stuff.
it was a west coast company that moved most operations to the east coast. however, the manager was still on the west coast, and wasn't seeing the day to day issues. In one major instance, I remember seeing that the initial 'customer info' screen was taking a LONG time to load. Like...30-40 seconds. In some cases, it was only a few seconds, but for important clients, it was taking a long time. They could vamp and chat for a bit, but it was getting worse.
The agents were hitting a webserver in california, and pulling HTML back, across a private network, and... it was a LONG time for older clients. It was pulling up the entire client history. For important clients - who did a lot of business - it was pulling back megs and megs of data.
When I looked under the hood, the data was being repeated - an entire block of data was being duplicated inside HTML comment tags - someone had put those in for debugging stuff and never got rid of it. So we were pulling back, say, 35 meg when maybe only 18 was needed. I simply deleted the commented info - it had not been touched in 6 months - commented the reason in the svn commit log, requested a new push go out, and the next day things were hugely faster.
I got my ass kicked. I "went behind someone's back" (untrue) and "jeopardized production systems" (untrue). Other people had seen the code and it was pushed out via normal process. It was simply the original developer didn't like that I'd highlighted something he'd forgotten to do. :(
I then angled for actually using gzip compression but was shot down at the time (no, "there's a bug in IE6 with gzip compression and printing" or something like that), even though the gzip would have brought this down to under 1 meg, and every call would have been 'up' in under 4 seconds.
We were further shielded from ever talking to CSRs, because they "might overload us with requests". It was (and still is) a bizarre rationale. :/
I work in a similar role where we previously did have a lot of contact with call centre folks, and the whole "overload us with requests" thing is very real. You become the go-to IT guy in no time at all, because if you make stuff for computers, surely when one breaks you can fix it, right? Or you could build something else in place of it? And suddenly, you have nearly no time to actually finish projects anymore. We had to distance ourselves by a floor and implement a ticketing system to avoid exactly this. Sounds like you had the opposite extreme though, which sucks just as bad but for the floor staff instead of the devops guys. Seems to be a fine balance.
It's not bizarre if you look at it from someone elses point of view: Someone (e.b. your manager, or your managers manager, or higher up) had said there wasn't anything they could do; you made them look bad.
It's stupid behavior as far as the company is concerned, but from whoever you made look bad, well, they stopped that from happening again, didn't they?
wasn't specifically a manager above me directly, but yeah, of course someone looked bad. other people looked bad directly to the people who were paying us money - our CS team said they kept raising the issue in meetings. just really bad rules - groups of people sitting literally 100 feet from each other not being allowed to talk and fix things.
My largest frustration with technology and specifically software developers is that they don't exist to code but most in the field seem to forget that simple fact.
They exist to solve real world problems for people, using software as a tool. I don't know how anyone can possibly do that even if they don't actively engage their user base and proactively solve workflow issues the end-users may not even know are technically possible.
Very frustrating to watch entire teams spend years on internal corporate business logic apps and never even once spend time with the teams consuming them. The results are always entirely predictable.
> They exist to solve real world problems for people, using software as a tool.
It's really, really frustrating when developers don't realize that. The most valuable thing I ever did at any company, saving just under a million dollars a year, was literally just me talking to three people, realizing that none of them were on the same page, and just talking to them to solve the problem.
More valuable than any code I've ever written. We're problem solvers, not just programmers.
Yep. I get told what to do by BA's at this company (I've had more direct interaction at some previous companies). I'm not allowed to talk with the users of the apps we make. I just get told what needs to get changed here by others. Presumably they're the ones going through that process.
To balanced it a bit, a lot of developers isolate themselves willingly against anything that is not obvious to involve coding immediately and throwing up their hands in despair - even if the work does involve coding a bit later on.
