Testing Zulip
-
@gjacobse 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?
Client to NTG Only - IIRC
How does that work? You'd have to do private groups or something if you're using a singular instance. Unless there's multiple Rocket.Chat servers running, one for each client?
How would you keep people at company A from talking to people at company B?
-
@Dashrender 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.
I'm sure it's not at no cost - but it's at like 5 cents/user/m or even less - it's most likely just baked into their monthly per user/device support fee.
I'm with the others pushing back on Scott though - are you saying any MSP worth it's salt is going to these lengths that NTG is to give awesome benefits at nearly no cost? Doesn't seem like making money is a goal here at all. Heck, even staying operating seems challenging at times. But really that would depend on your profits on the existing fees, perhaps you're already making 100% met margins, so this expense of labor would be worthwhile.
Yeah not even the free part. How do you track any of this? Tickets come in on a system built for internal chat (and external through public channels obv). How do you keep track of any of that? Unless you set webhooks or something to create tickets in a ticketing system, which at that point, just have them submit tickets? I don't understand this workflow at all.
-
@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.
-
@stacksofplates said in Testing Zulip:
@Dashrender 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.
I'm sure it's not at no cost - but it's at like 5 cents/user/m or even less - it's most likely just baked into their monthly per user/device support fee.
I'm with the others pushing back on Scott though - are you saying any MSP worth it's salt is going to these lengths that NTG is to give awesome benefits at nearly no cost? Doesn't seem like making money is a goal here at all. Heck, even staying operating seems challenging at times. But really that would depend on your profits on the existing fees, perhaps you're already making 100% met margins, so this expense of labor would be worthwhile.
Yeah not even the free part. How do you track any of this? Tickets come in on a system built for internal chat (and external through public channels obv). How do you keep track of any of that? Unless you set webhooks or something to create tickets in a ticketing system, which at that point, just have them submit tickets? I don't understand this workflow at all.
I can't speak to any of that.
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.
-
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@gjacobse said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
@stacksofplates said in Testing Zulip:
@scottalanmiller said in Testing Zulip:
Rocket is no longer going to do notifications for free,
It shows you get 5 thousand for free per month?
Yeah, doesn't seem like nearly enough for us. We've hundreds of users and constant chatter. Seems like we could go through that in a few days.
How many users do you have? Seems like a good investment to pay the $3 a month to support Rocket.Chat.
Edit: Or go SaaS with them and pay $2 a month and have no limit for notifications at all (and not have to manage anything). That seems like a crazy deal.
Edit2: Sorry missed the hundreds. You have hundreds of employees?
Hundreds of NTG employees? No -
But NTG client employees number in the hundreds - and they use it as a point of contact other than phone or mail
Then it's a no brainer. The $2 should be built into the support cost. The employee cost for it should be minimal.
That's not viable MSP math. You start doing that and suddenly every tool costs you tens of thousands of dollars and you spend so much supporting a person that no one can afford you.
There is a reason why $3/mo RMM tools don't make sense, it's too costly on an end point / person basis. Individual endpoints or people should be cheap. If the ENTIRE cost was $2 well heck, yeah. But once you start down this path you pay $2 here, $2 there and suddenly you're spending more per user on tooling than most companies charge for support.
The idea that you just bill the customer for you not keeping the cost down sounds great, but in reality, being the company that delivers more value for less money goes a long way.
Wait so instead of a support portal you create a user for anyone from the customer who wants to talk to you guys?
Yes, because we are a full IT department and we provide it as intracompany communications. We could use a support portal, and Rocket makes that as an option, but we need two way communications, not one way, so a more traditional IM platform tends to work much better.
We have customers that require us to use their own Slack, Teams, etc. but this is for all the customers that don't have one of their own to put us on.
-
@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.
Closer to a thousand, but yeah, in that ballpark.
-
@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?
Customer pays us for IT services. If we spread the cost out amongst all customers, the cost to each customer is nominal. If we make it a hard $2/user it becomes an awkward line item and endless questions as to why we don't just use a free service.
This is way more cost effective for us than answering account questions and/or using a bunch of disconnected services.
-
@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.
