Our Premier Field Engineers travel a lot.  When customers need assistance during deployments or need a workshop or want to make sure their team is up to speed on what we're delivering, they request us to be onsite and we come on out.  The opportunity to be out working directly at the customer site greatly improves communication and our ability to teach customers or accomplish the key tasks for them.  I encourage the team to go visit new customers as an opportunity to build a relationship with the key contacts there.

With all that said, there are also many, many opportunities in today's world to solve key technical issues remotely.  A few years ago, I was onsite at a customer in Portland, OR and I went to meet the partners who were working on the implementation.  They were all sitting together in one conference room away from the IT area and they hadn't talked to the customer directly in a couple days.  That was a clear example to me of when an onsite may not be as necessary. 

With that said, here are my top 5 situations where remote delivery of implementation services, optimization services or troubleshooting can be delivered remotely:

  1. Performance Services - when we're looking at performance of the system (an everyday activity for at least 1 person on the team), we have the Performance Analyzer for Dynamics toolkit that we use to gather information from across the Dynamics deployment.  When we get a chance to review that database backup, we can find a ton of good information in the system without having to take time away from the DBA or IT professional.  Doing this same work at the customer site really makes it no faster, the key benefit for the onsite portion of the service is to treat it like our Performance Hands on Lab service where we train people as we review the data.  We can also talk to more users on the ground to understand what performance pain they are seeing, but a lot of that can be found within the data we collect.
  2. System Troubleshooting - quite a few times when our support engineers are engaged in a system down or work stoppage situation, they request an engineer to go onsite to help resolve the issue.  This actually slows down the process, because the engineer has to drop what he's doing, get packed up and find the next available flight, which oftentimes costs the process many hours.  I understand why customers ask for this - they want to be certain the engineer is fully dedicated to solving their issue.  We have a policy that for Severity A cases (critical situations) we have engineers working on the issue 24x7 until the situation is resolved or the severity is lessened (provided that the customer is working with us throughout this time).  The best way to make the customer feel better about this though is to make sure we're giving consistent updates on the situation.  When I dealt with these issues, I would tell the customer we'd have an email update every 3-4 hours to make sure they are aware of the status (and can forward it to their internal stakeholders who are probably putting the pressure on them).  We also set up regular calls so there are clear expectations set on the communications front.  This is critical to giving customers the confidence they need that this is your one and only priority.
  3. Customer Personnel in Many Locations - I see this happening more and more with hosted sites or distributed sites where customer personnel are not in one location.  They often bring up the fact that onsites are not necessary due to the fact they are not all in the same place.  The advent of Lync and especially the Roundtable conferencing system makes it easy to share screens and video-conference to make sure you're feeling connected while in various locations.
  4. Document Writing - this goes to the example above where consultants were onsite, but holed up in a conference room writing Technical and Functional Specs.  If I'm a customer, I'd rather not pay for the travel and expense costs associated with having a consultant come up for the week period they are spending writing their documentation on the system.  Consultants can focus better when they are writing this off-site as well, so I think it's better for all involved.  This includes our Infrastructure Design service where we ask customers a series of questions and then create a proposed infrastructure design for their Dynamics systems.  We hardly ever go onsite for this, because we aren't talking about existing hardware, we're taking inputs and then spending several days putting those inputs into the best possible design document to support their solution.
  5. Diagnostic Service Delivery - we deliver our Health Check services more often than any other service, and we do a little more than half of them remotely.  It's great to go onsite for the delivery, especially if it's our first trip to visit the customer so we can build that relationship and provide knowledge transfer while we deliver it.  However, if the customer's IT staff is busy, and they really want the independent review of the risk in their system, it's great to collect and deliver this service remotely.  As with the performance service, we can gather all the information by dialing in and from there we need time to write up the document highlighting the key areas of concern.  We often go onsite to deliver the results, but regardless of how that's delivered, it's very important that we have a review of that document where action items are discussed and taken to make sure to reduce risk in the implementation.

We've done some remote trainings and I've done several of them personally where I've been bored listening to myself after an hour (let alone how bored the listeners must be).  There are ways around this - incorporate video, ask a ton of questions, break for labs throughout the session - so I still think remote training can be effective if done correctly.  However, if you have a slide deck and a phone, I can already say it's not going to go great.

Let me know if you have any feedback or items to add to the list.

Eric Newell