Testing Zulip
-
@scottalanmiller said in Testing Zulip:
@VoIP_n00b said in Testing Zulip:
@scottalanmiller what's your time worth?
MY time? What does MY time have to do with it?
I think you intend to as how much the time of my staff is worth. And we've already established that I can save a lot by hiring someone to run this system rather than paying $2/mo.
I covered that, so there should be no question that the savings from building, rather than buying, is huge no matter how it is worded.
Let's assume you have 100,000 supported end users, your engineer costs you $120k/y, yeah, $2*200,000 = $400,000, you definitely have a savings.
But as @stacksofplates has said - are you not passing along the cost of that engineer to the customer? Let's assume you are, $120,000/200,000 = $0.60/year = 5 cents a month. So we assume you're tacking in 5+ cents a month per end user to the support contracts to cover his costs? and this is before the server/power/hosting/whatever expenses (granted those are likely WAY lower).
-
@jmoore said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@gjacobse said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
At that price, we were able to afford to hire a full time engineer just to build and support a solution to replace it and were able to provide a vastly superior solution to the customers, at lower cost
You hired an engineer for $600 a month?
I'm guessing because "hundreds" doesn't tell me anything. So I'm going with 200 people.
While it’s been two or so years since I was an active NTG staffer, one client would have had 200 employees in just one state, and they where in all 50.
Rocket was a good process as it allowed for whole company separation and still include notifications like down time. But also allowed for the personalization of direct contact that wasn’t a flood to NTG
Wait a minute. So NTG is offering Rocket.Chat as a service to customers for internal communication along with using it as a means of notifications for SLOs?
And at no cost to the customer?
Yeah I'm not understanding this line of reasoning either. I get they want to be cheap to get business, but at some point it's not going to work as well as clients need as they often need hand-holding.
It's less a desire to be cheap, and more a desire to provide a premium service. Would you want your IT company to not be easy to communicate with bidirectionally? Very few companies want an IT department that is set apart and not an active participant in the business.
-
@Dashrender said in Testing Zulip:
Scott is so gun-ho for Email is the ruler of them all - I would suspect that only email generates tickets, and Rocket.chat is only for chatting.
No, I'm "pro appropriate tools", you just perceive that as email being the only thing I like because email is more often appropriate than most people think.
We are a premium service with high end customer service. We work far more by phone and IM, than by email, because it's what our customers pay us to do.
You are mixing "how I'd want my own business run" with "how we provide customer service to others." They are different things. I don't want a burger cooked well done, I want it rare. But good customer service lets the customer decide how to cook their burger, even if we think that it is gross that way.
-
@Dashrender said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
@VoIP_n00b said in Testing Zulip:
@scottalanmiller what's your time worth?
MY time? What does MY time have to do with it?
I think you intend to as how much the time of my staff is worth. And we've already established that I can save a lot by hiring someone to run this system rather than paying $2/mo.
I covered that, so there should be no question that the savings from building, rather than buying, is huge no matter how it is worded.
Let's assume you have 100,000 supported end users, your engineer costs you $120k/y, yeah, $2*200,000 = $400,000, you definitely have a savings.
But as @stacksofplates has said - are you not passing along the cost of that engineer to the customer? Let's assume you are, $120,000/200,000 = $0.60/year = 5 cents a month. So we assume you're tacking in 5+ cents a month per end user to the support contracts to cover his costs? and this is before the server/power/hosting/whatever expenses (granted those are likely WAY lower).
So are we tacking it on as a specific line item? No. Are we including all that cost in their contracts, yes. It's just part of the background infrastructure in the same way that every MSP automatically includes the cost of phone minutes or email hosting or whatever.
In the end, customers always pay for all services, always. The only exception is a company that has no income. Everything we do, one way or another, is paid for by the customers as that is the only source of money. This is true of all businesses. The only question is whether or not we expose the cost structure to the client, and the answer is no because that would be confusing, costly, and unnecessarily complex when we are able to keep the cost so low that it is background noise.
If we were charging several dollars per person, then customers would start demanding to control the line item like reducing who gets to communicate and undermine our ability to do a good job. By keeping it "background noise" cheap and just part of the infrastructure, it's so cheap that there is no discussion, just like there isn't for email or phone minutes.
-
@scottalanmiller said in Testing Zulip:
@Dashrender said in Testing Zulip:
Scott is so gun-ho for Email is the ruler of them all - I would suspect that only email generates tickets, and Rocket.chat is only for chatting.
No, I'm "pro appropriate tools", you just perceive that as email being the only thing I like because email is more often appropriate than most people think.
We are a premium service with high end customer service. We work far more by phone and IM, than by email, because it's what our customers pay us to do.
You are mixing "how I'd want my own business run" with "how we provide customer service to others." They are different things. I don't want a burger cooked well done, I want it rare. But good customer service lets the customer decide how to cook their burger, even if we think that it is gross that way.
Don't over read into what I said - I just said gun-ho, nothing more, nothing less... now perhaps that we a bit inaccurate because, as you said, Pro appropriate tool - would likely have been a better thing for yo to be gun-ho over
-
@scottalanmiller said in Testing Zulip:
@Dashrender said in Testing Zulip:
Scott is so gun-ho for Email is the ruler of them all - I would suspect that only email generates tickets, and Rocket.chat is only for chatting.
No, I'm "pro appropriate tools", you just perceive that as email being the only thing I like because email is more often appropriate than most people think.
We are a premium service with high end customer service. We work far more by phone and IM, than by email, because it's what our customers pay us to do.
You are mixing "how I'd want my own business run" with "how we provide customer service to others." They are different things. I don't want a burger cooked well done, I want it rare. But good customer service lets the customer decide how to cook their burger, even if we think that it is gross that way.
How do you track any of that? Unless people now have to enter things in multiple systems?
-
@scottalanmiller said in Testing Zulip:
@Dashrender said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
@VoIP_n00b said in Testing Zulip:
@scottalanmiller what's your time worth?
MY time? What does MY time have to do with it?
I think you intend to as how much the time of my staff is worth. And we've already established that I can save a lot by hiring someone to run this system rather than paying $2/mo.
I covered that, so there should be no question that the savings from building, rather than buying, is huge no matter how it is worded.
Let's assume you have 100,000 supported end users, your engineer costs you $120k/y, yeah, $2*200,000 = $400,000, you definitely have a savings.
But as @stacksofplates has said - are you not passing along the cost of that engineer to the customer? Let's assume you are, $120,000/200,000 = $0.60/year = 5 cents a month. So we assume you're tacking in 5+ cents a month per end user to the support contracts to cover his costs? and this is before the server/power/hosting/whatever expenses (granted those are likely WAY lower).
So are we tacking it on as a specific line item? No. Are we including all that cost in their contracts, yes. It's just part of the background infrastructure in the same way that every MSP automatically includes the cost of phone minutes or email hosting or whatever.
In the end, customers always pay for all services, always. The only exception is a company that has no income. Everything we do, one way or another, is paid for by the customers as that is the only source of money. This is true of all businesses. The only question is whether or not we expose the cost structure to the client, and the answer is no because that would be confusing, costly, and unnecessarily complex when we are able to keep the cost so low that it is background noise.
If we were charging several dollars per person, then customers would start demanding to control the line item like reducing who gets to communicate and undermine our ability to do a good job. By keeping it "background noise" cheap and just part of the infrastructure, it's so cheap that there is no discussion, just like there isn't for email or phone minutes.
no, it never needs to be a line item... it's just inside the pricing you provide, but your pricing includes these expenses. If you raised your rate by $2/user/month, you're saying that you'd price yourself out of business?
I guess as long as there are good usable free tools, then you're right, you should go that route, as long as those free tools cost you less than $2/user/month, or at least whatever portion of your monthly fee is allocated to this benefit you're giving your customers.As an aside - Cox has recently decided that providing "free" email services to their ISP customers is no longer viable. They have dumped email for all new customers. I'm assuming at some point they will dump it for grandfathered users as well.
-
I'll give another example that I think shows a similar case that "feels" different. We use MeshCentral for remote access/support. We don't charge for it as a line item for our existing customers (or new ones, lol.) The cost of it is crazy low on a per machine basis. Just having one conversation with a customer about where they want to pay for it and where they don't would waste an unacceptable amount of money for no gain. It's heavily to both our benefit and our customers' to have it in place. Everyone wins by making it universal and keeping the cost so low that no one notices.
If we broke it out, the cost of managing the accounts, tracking where it is deployed, discussing with the clients would easily cost $1/machine or more. By not doing that and simply deploying all/none on a client by client basis keeps the cost to a few pennies. It's deployed by script, it's managed in a blanket way that makes cost really, really low. So instead of a dollar per machine, it's more like a dollar per customer. Background noise. Everyone benefits.
-
@stacksofplates said in Testing Zulip:
How do you track any of that? Unless people now have to enter things in multiple systems?
Are you asking how do we keep from losing track of a request? Like Sue asks for Filezilla to be installed via email. And Betty asks for WinSCP to be installed via phone. And John requests a new phone extension by instant messenger. And Jorge asks for a new laptop straight through a ticket portal?
If that is what you are asking, two of those (email and portal) make tickets automatically. The other two are picked up by the customer service team (aka triage) who put in a ticket for the customer. This often works really well because they are able to ask questions and get some clarification on some things before the initial ticket goes in.
The actual techs doing the work get everything via ticket. We only work from tickets. But we have a helpdesk that will put in tickets for customers however they want to put them in. Of course, email or the portal are faster since you don't need to discuss it with someone or wait for a human, but if you need the customer service touch of a human, we are here for them.
-
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
-
@scottalanmiller said in Testing Zulip:
I'll give another example that I think shows a similar case that "feels" different. We use MeshCentral for remote access/support. We don't charge for it as a line item for our existing customers (or new ones, lol.) The cost of it is crazy low on a per machine basis. Just having one conversation with a customer about where they want to pay for it and where they don't would waste an unacceptable amount of money for no gain. It's heavily to both our benefit and our customers' to have it in place. Everyone wins by making it universal and keeping the cost so low that no one notices.
If we broke it out, the cost of managing the accounts, tracking where it is deployed, discussing with the clients would easily cost $1/machine or more. By not doing that and simply deploying all/none on a client by client basis keeps the cost to a few pennies. It's deployed by script, it's managed in a blanket way that makes cost really, really low. So instead of a dollar per machine, it's more like a dollar per customer. Background noise. Everyone benefits.
Yes, I completely get it, this is no different than what I mentioned above - but it's still not zero cost to you. So you put it in the whatever GL catagory, instead of direct passing the cost down to the customer, no different than intel putting the cost of fabrication equipment into some general internal line item, because you could never break it out on a per items type basis, that's, as you mention, not cost effective... BUT you still have to have an otherwise higher end user fee because of that service than if you didn't offer that service, and if not higher fee, then lower profits, tomato tomato..
-
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
-
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Well, he's not alone - my boss constantly takes phone calls, she can't allow technology to do it's job - i.e. go to VM, we'll call them back.
-
@Dashrender said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Well, he's not alone - my boss constantly takes phone calls, she can't allow technology to do it's job - i.e. go to VM, we'll call them back.
Is your boss the CIO/CEO? They are taking the calls so that the manager doesn't have to. Does your CEO take calls so your manager doesn't have to?
-
@stacksofplates said in Testing Zulip:
@Dashrender said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Well, he's not alone - my boss constantly takes phone calls, she can't allow technology to do it's job - i.e. go to VM, we'll call them back.
Is your boss the CIO/CEO? They are taking the calls so that the manager doesn't have to. Does your CEO take calls so your manager doesn't have to?
Yeah, my boss is basically the CEO (medical practices don't call them that - they generally call them Office Managers).
no, my boss is taking them along with the manager taking them. It is weird that Scott would want the call before the manager of the HELPDESK personal - what is that manager doing that's so much more valuable than answering the phone? What makes what they are doing more valuable than Scott evaluating the next replacement for Rocket.chat for the company to not spend money on?
-
@Dashrender said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@Dashrender said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Well, he's not alone - my boss constantly takes phone calls, she can't allow technology to do it's job - i.e. go to VM, we'll call them back.
Is your boss the CIO/CEO? They are taking the calls so that the manager doesn't have to. Does your CEO take calls so your manager doesn't have to?
Yeah, my boss is basically the CEO (medical practices don't call them that - they generally call them Office Managers).
no, my boss is taking them along with the manager taking them. It is weird that Scott would want the call before the manager of the HELPDESK personal - what is that manager doing that's so much more valuable than answering the phone? What makes what they are doing more valuable than Scott evaluating the next replacement for Rocket.chat for the company to not spend money on?
There's no reality where I can be convinced that it's useful to have the CEO/CIO answering the phone when you can somehow get a competent systems engineer for $5-6 an hour. At that rate a helpdesk person should be $3 an hour. There isn't a universe where having more helpdesk people to answer the phones makes less sense than the highest paid people in the company.
-
@scottalanmiller said in Testing Zulip:
@jmoore said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@gjacobse said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
At that price, we were able to afford to hire a full time engineer just to build and support a solution to replace it and were able to provide a vastly superior solution to the customers, at lower cost
You hired an engineer for $600 a month?
I'm guessing because "hundreds" doesn't tell me anything. So I'm going with 200 people.
While it’s been two or so years since I was an active NTG staffer, one client would have had 200 employees in just one state, and they where in all 50.
Rocket was a good process as it allowed for whole company separation and still include notifications like down time. But also allowed for the personalization of direct contact that wasn’t a flood to NTG
Wait a minute. So NTG is offering Rocket.Chat as a service to customers for internal communication along with using it as a means of notifications for SLOs?
And at no cost to the customer?
Yeah I'm not understanding this line of reasoning either. I get they want to be cheap to get business, but at some point it's not going to work as well as clients need as they often need hand-holding.
It's less a desire to be cheap, and more a desire to provide a premium service. Would you want your IT company to not be easy to communicate with bidirectionally? Very few companies want an IT department that is set apart and not an active participant in the business.
Oh sure good communication means a lot so I can see this point. I am just thinking about the free services that are available and if any will ultimately meet your customer needs.
-
@Dashrender said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
I'll give another example that I think shows a similar case that "feels" different. We use MeshCentral for remote access/support. We don't charge for it as a line item for our existing customers (or new ones, lol.) The cost of it is crazy low on a per machine basis. Just having one conversation with a customer about where they want to pay for it and where they don't would waste an unacceptable amount of money for no gain. It's heavily to both our benefit and our customers' to have it in place. Everyone wins by making it universal and keeping the cost so low that no one notices.
If we broke it out, the cost of managing the accounts, tracking where it is deployed, discussing with the clients would easily cost $1/machine or more. By not doing that and simply deploying all/none on a client by client basis keeps the cost to a few pennies. It's deployed by script, it's managed in a blanket way that makes cost really, really low. So instead of a dollar per machine, it's more like a dollar per customer. Background noise. Everyone benefits.
Yes, I completely get it, this is no different than what I mentioned above - but it's still not zero cost to you. So you put it in the whatever GL catagory, instead of direct passing the cost down to the customer, no different than intel putting the cost of fabrication equipment into some general internal line item, because you could never break it out on a per items type basis, that's, as you mention, not cost effective... BUT you still have to have an otherwise higher end user fee because of that service than if you didn't offer that service, and if not higher fee, then lower profits, tomato tomato..
Sometimes. It may not actually be higher, it can be lower. But either way, the cost is so low on a per customer / user basis. That's the important part.
-
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Better than having them sit idle and not know what's going on in the company because they are so disconnected. At some point, those roles have to have jobs.
I took one those calls tonight and am hoping it's over $100K of benefit because I did so. I definitely don't have many hours that make more money than that. Now, is it certainly $100K? No. Likely, actually yes. Keeping tabs on operations can have value.
-
@Dashrender said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
We have a separate team that deals just with customer service handling. We try hard to never let phones go to voicemail, and I think we only see that once every several months (like two to three times a year.) We have a tiered desk that answers the phones, then their managers and a few techs who have volunteered take calls if the front line is overwhelmed, which is rare since Paul and I ring with the front line so if they are swamped, we tend to know and can grab calls before they go to managers like @valentina and then we typically, depending on the path, have a third tier that can catch most calls if they fall through both of those levels and if, by some unbelievable situation, it makes it all the way through the third tier, it goes to voicemail that automatically emails everyone to find someone to deal with a customer that's tried to call and couldn't get through. THEN a tech might respond immediately because they couldn't get to triage. But like I said, 2-3 times a year. It's rare and we staff up to make sure it stays at about that rate.
Generally the front line takes a call, puts in a ticket while on the phone, finds the right tech, and transfers (along with the ticket and notes) directly to the tech. It's not a delaying tactic, it's to allow the triage layer to find the right resource that both has the right technical skill set and is currently available to step in. Otherwise, we'd have techs grabbing the phone and you might be calling about a printer and get a storage guy or something.
The CEO and CIO are taking helpdesk calls? That cannot be a good use of company money? That just seems crazy.
Well, he's not alone - my boss constantly takes phone calls, she can't allow technology to do it's job - i.e. go to VM, we'll call them back.
Well, she could argue that VM's job is to catch when IT can't get to it, and by picking it up, IT did it's job and got to it. So the VM was still doing its job, it just didn't have to do anything because IT also did its.
