In this section …

• Overview
  • Demos
  • POC
  • Production

Overview

I have already explained how The USD Accelerator can help speed the introduction of USD and therefore increase your return on investment for USD. In this section I will give a much more detail around when and how it can be used for customer demos, proof of concepts and even production use.

Obviously, each organisation and project is unique and you will need to adjust this approach to fit your needs / business culture etc. I have created these observations based on my real experiences gained running multiple Unified Service Desk projects. They may not reflect how you could or should run your project but should at least constitute some food for thought.

Demos

Occasionally your business may express a specific interesting in Unified Service Desk but often the need will simply state that the contact centre is struggling with some specific business requirement. Before management can contemplate USD they may need an out of the box demo to get a flavour of how it might be applied to their specific business need.

I have often used The USD Accelerator to support these types of demos. Yes, at this point you could simply demo the Microsoft sample package for Unified Service Desk. If that approach works for you that is great. However the Microsoft’s sample package only covers scenarios with cases, doesn’t include CTI and won’t include many of the standard features commonly required in a contact centre. Plus, The USD Accelerator demos can’t be tailored. (By using USD options to enable / disable features as required.)

I have completed countless demos of Unified Service Desk using The USD Accelerator. When I have approached a demo, I have simply installed The USD Accelerator and then disabled any major features which aren’t required. For example, if you don’t use Field Service that should be excluded. My intention at this point isn’t to “hide” features but simply help the audience understand the context by removing any “clutter” that isn’t relevant to them.

It takes me just a couple of hours to create a demo. Maybe a day maximum for a complicated demo. (You should be allowing more preparation time to create your slides and decide what needs to shown rather than worrying about the technology!)

Demos are typically done using a 30 day free Microsoft Dynamics 365 trial instance.

POC

Assuming your demo goes well you maybe asked to progress to the next stage. Which commonly is to create a proof of concept. This will typically not include all the required functionality but will involve data, screens and business processes familiar to your business. The context provided by a proof of concept can often given senior management the clarity needed to decide to invest in a wider project or not.

A proof of concept system can also be an invaluable tool when entering initial requirements workshops. It can help end users gain a vision of what might be possible, once they do that I often find the number and quality of stated requirements increases.

At the start of a proof of concept project you may want to give some thought as to expected outcomes. In my opinion, there is no such thing as a failure with a POC! The point is to build something quickly and if the concept doesn’t work for your organisation to “fail” quickly. It is better to look at an idea and rule it out quickly then engage in a full project and after many months decide to write off the work as a costly failure. One POC I ran showed the business that they simply weren’t ready for USD, the POC highlighted several issues with the telephony solution and overall Dynamics 365 design. It was felt that resolving those first would be the right course of action. From a Unified Service Desk point of view this might be considered a failure but the business learnt some valuable lessons and adjusted their IT roadmap as a result.

Typically, in a POC I will spend a little more time thinking about what options will and won’t be useful to the business. I commonly try to disable as much as possible at this point. The cleaner the interface the easier it becomes to see the intended vision.

Almost always sessions will start in the context of an account, contact and / or lead. So, the basic logic of searching and opening these entities tends to be common to most proof of concepts. But commonly you’ll want to include several custom entities into the navigation. (At least you will assuming the business may already be using Dynamics 365 and at least the main entities will already exist.)

It has been a common ask to include some more complex integrations in a POC. I would often suggest investigating what is involved with these but at this stage I wouldn’t always recommend investing large amounts of development time. Maybe some mock up screens should be used to show what could happen in a production system. I would suggest the point of a proof of concept system is to show the art of the possible not build a finished system!

I have typically tried to confine the initial POC to 2 to 3 weeks work. The proof of concepts I have run have typically involved a small number of key staff. Maybe a business stake holder, plus someone technical who has an understanding of the existing Dynamics 365 system and one person who will create the USD configurations.

I have completed POC work in trial instances but more often than not a POC will be completed in a sandbox instance within your existing Office 365 tenant. In most projects this has been a sandbox isolated from all other development work, as you might want to discard the POC and will want to avoid impacting other development activities.

Production

So, your demo went well, it progress into a POC that the management wants to progress. Great but before you start to build anything our first question should be “will we use The USD Accelerator as a base or will we create a bespoke config. There is no right or wrong answer to this question. In the last few years I have taken both approaches.

Maybe the business requirements are very simple and could be created from scratch with little effort. Or maybe the requirements are very bespoke and complex, requiring significant effort. In these extreme cases you may decide to only use The USD Accelerator as a demo / learning tool. In which case you’d begin a project to build a custom configurations from scratch.

Even in projects when I haven’t used The USD Accelerator as an actual basis for the production system I have used it as an R&D test bed. Say you want to experiment with some ideas just to see how they might perform or to contrast one development approach with another. Sometime The USD Accelerator has been a useful tool to support this R&D effort.

In other projects I have found that The USD Accelerator might actually be a close fit without any changes. Maybe it is an 80% fit with little or no changes. When this has happened The USD Accelerator has become a basis for my production build. Think of it as a starting template. But once you have started to modify this template then it is no longer The USD Accelerator, as it will have become your solution.

In the initial build stage of the project you will want to get the basic functionality working. I suggest in this phase you concentrate on adding the additional functionality you require and don’t worry overly about performance. (That will come later.) I have typically worked in sprints to gradually adding functionality until we have reached a point that contains enough functionality to consider a live deployment. The rough steps / stages I have followed are described below;

1. Clone one of the USD configurations, start adding your changes into that.
2. Enable / Disable features as required.
3. Add navigation for additional entities. (Most implementations will involve adding some custom entities into the config.)
4. Add any custom configurations.
5. Refine / define agent scripts.

Once you have a configuration that meets (or almost meets) the required requirements you will no doubt want to optimise it before final testing and deployment. It is only in this final stage that I start to remove functionality.

But this final optimisation step can be important. The USD Accelerator is a large configuration, if your production system will only ever use a limited subset of entities you wouldn’t want to deploy all of this “bloat” into production. Therefore, the final part of the build involves removing unwanted hosted controls, actions, toolbars, agent scripts and window navigation rules from the configuration. Often I have actually deactivated items that I am confident will never be needed. This will make your configuration smaller and therefore easier to support and also potentially faster.

Project teams for production will probably grow compared to those used in the POC. You may require to make some Dynamics 365 changes or include some bespoke integrations, so developers may come into the picture. A greater number of business stake holders will typically be involved. As will other supporting roles, examples being business analysts, testers, trainers etc. The exact make up of your project team will vary depending on the project size. But as with any project, making sure you have the right people doing the right jobs will be important!

Back to Technical Guide …