I recently got a new job at a software company. We develop a line of business application that is most of our client's most important software that they run.
Our clients vary from having their own IT, to having an MSP, to not really having any IT - they just call someone for break-fix. For the most part, right now I'm just thinking about MSPs
I believe that in an ideal world, IT and Dev needs to work together to ensure that a business runs smoothly.
However, what often happens is back and forth finger pointing and poor communication between the two, especially since the IT company is not actually our client.
What I want to happen is to stop the finger pointing, and increase communication so that together, us and MSPs can effectively service the needs of our joint clients.
I have two questions.
How do we increase communication with their third-party IT? If this communication isn't included with their contract, then clients could potentially be getting billed if we want to go this route. Should we be communicating directly to MSPs, or should we be using a proxy (should it be a specific person?) within the client company in order to 'oversee' communications and relay information over to their IT?
How does our tech support 'play nice' when some else has set up the infrastructure? Where do we draw the line on things we should touch without contacting IT? I feel like, the user we are helping's permissions could help us draw the line. i.e "if the user has permissions to do it, and they say it's okay, then we can go ahead"
However, the flaw with that is that if our program isn't running on a remote desktop server, we mostly recommend users to be local admin. I know, this raises a lot of red flags, and hopefully soon we can remove that recommendation. The problem is that we require the application to be updated a couple of times a week, and while the update utility can be scheduled, some of our deployments require user intervention (i.e. an 'OK' button pops up) and thus an update would fail until the update is run manually.
So since that is a strong recommendation, I feel like a lot of users wouldn't be given local admin by IT otherwise.
Some examples of things we might do:
If their computer that distributes the application updates locally is Windows 10, then an update borks the share permissions, then we set the permissions back to what we think they should be. (I feel like we probably should actually only have to give IT the share requirements, and then it is their duty to ensure those share permissions stay correct)
Application keeps crashing, we can't find cause and so suspect corrupted windows profile, and thus we create another user account on the computer in order to test to see if the program still crashes. If we didn't test this ourselves, it's kind of like "I suspect this the issue but not 100% certain, but we want you to pay a tech in order to make sure, even though that might not be the problem"
Where would you want software support to draw the line with your clients, and how to do you want to communicate with them?
Our clients vary from having their own IT, to having an MSP, to not really having any IT - they just call someone for break-fix. For the most part, right now I'm just thinking about MSPs
I believe that in an ideal world, IT and Dev needs to work together to ensure that a business runs smoothly.
However, what often happens is back and forth finger pointing and poor communication between the two, especially since the IT company is not actually our client.
What I want to happen is to stop the finger pointing, and increase communication so that together, us and MSPs can effectively service the needs of our joint clients.
I have two questions.
How do we increase communication with their third-party IT? If this communication isn't included with their contract, then clients could potentially be getting billed if we want to go this route. Should we be communicating directly to MSPs, or should we be using a proxy (should it be a specific person?) within the client company in order to 'oversee' communications and relay information over to their IT?
How does our tech support 'play nice' when some else has set up the infrastructure? Where do we draw the line on things we should touch without contacting IT? I feel like, the user we are helping's permissions could help us draw the line. i.e "if the user has permissions to do it, and they say it's okay, then we can go ahead"
However, the flaw with that is that if our program isn't running on a remote desktop server, we mostly recommend users to be local admin. I know, this raises a lot of red flags, and hopefully soon we can remove that recommendation. The problem is that we require the application to be updated a couple of times a week, and while the update utility can be scheduled, some of our deployments require user intervention (i.e. an 'OK' button pops up) and thus an update would fail until the update is run manually.
So since that is a strong recommendation, I feel like a lot of users wouldn't be given local admin by IT otherwise.
Some examples of things we might do:
If their computer that distributes the application updates locally is Windows 10, then an update borks the share permissions, then we set the permissions back to what we think they should be. (I feel like we probably should actually only have to give IT the share requirements, and then it is their duty to ensure those share permissions stay correct)
Application keeps crashing, we can't find cause and so suspect corrupted windows profile, and thus we create another user account on the computer in order to test to see if the program still crashes. If we didn't test this ourselves, it's kind of like "I suspect this the issue but not 100% certain, but we want you to pay a tech in order to make sure, even though that might not be the problem"
Where would you want software support to draw the line with your clients, and how to do you want to communicate with them?
