jump to navigation

Cases, Jobs and Work Orders in Microsoft CRM & FieldOne Sky March 8, 2016

Posted by Ivor's Window to the IT and CRM World in CRM, FieldOne Sky, Microsoft CRM 2016, Microsoft Dynamics CRM, service management, Uncategorized.
Tags: ,
add a comment

single van on move

This is the second in a series of posts relating to FieldOne Sky, the new Field Service module that is available within Microsoft Dynamics CRM.

The first post can be found here: https://ivorw50.wordpress.com/2016/02/11/field-service-management-in-microsoft-crm-fieldone-sky/

Right from the start, Microsoft Dynamics CRM has had a service module. It had basic case management and a knowledge base, in recent years this has been with the introduction of SLA’s entitlements, routing rules and case creation automation, and an overhaul to the knowledge base.

Case management is the natural pre cursor to service management, for example a customer calls in with a problem, a case is raised and thereafter a technician is despatched to resolve the issue. They are in effect complementary activities when looked at from the overall service perspective.

Case management can stand on its own, and the Unified Service Desk offering within Microsoft CRM may be all that some companies require where the case creates a simple job which may be handled by a service team. A good example of this is where every job is exactly the same and there is no need to specifically schedule the work. This could relate to someone who just has to read a meter at various locations during the day.

FieldOne Sky however is predicated on the notion of a Job or Work Order which is spawned by a case. There are obvious exceptions to this rule, however most of the scenarios outlined in the previous blog all could be linked to a case record. From the local government official sent out to inspect and report on compliance to the delivery person scheduled to deliver a new fridge, all of these work order records could be created from a case or incident record.

There is something that needs to be done, information about the work is recorded and the person undertaking the work will be obliged to update this information and probably indicate a time of arrival and departure in order to facilitate billing. This is what a work order is all about.

Let us look at two of the many fields that are found on a Work Order to explore the scale of the application.

Primary Incident Type

An Incident or Case can have a type for example “broken stove”, this incident type will have a number of characteristics associated with the type. These include the Default Work Order Type, the Duration and whether this incident must inherit data from agreements or contracts.

What this means is that just by creating a case of a particular type, the resultant Work Order is going to be populated with data that has been set up in the background.

The type of work order will be used to determine the specific resources that are required in order to complete the work, and are available to be scheduled based on current availability. The reality for many field service managers is that “everything is urgent” and a lot of flexibility is often required to manipulate the schedules to see that everyone ends up happy. Therefore the scheduling engine needs to be sophisticated enough to deal with this reality.

In order to highlight the deep drill down complexities of the FieldOne Sky application let us look at another field on the work order that drills down to other records which in turn drills down to more records.

Primary Incident Customer Asset

Another capability of the system revolves around the identification and intelligent recording of customer assets. The Asset record in CRM is the repository for data about a specific asset as can be seen below. Therefore a case and the resultant work order can be related to an asset.

Assets can have parent records and even be linked to a “Master Asset” and have “Sub Asset” levels to allow for granular componentry. Leveraging the standard CRM product module an asset can even be known and discovered with a price, unit of measure, and be linked to relevant price lists.

 CRM Asset


The preferred resource can be set on an asset. When you drill down to resource you are able to discern that it contains all the information relating to the capabilities, skills, rates, locations etc. of the resource to be used in the algorithm for scheduling. The preferred resource could be a vehicle with an inventory of spares, which could be classified as a warehouse from a system perspective.

Once configured correctly, a work order created as an outcome of a case has all of the metadata required in order to provide the person attending the call with all of the relevant information to perform the work, and report back, effectively closing the case once complete.

Therefore as can be seen, just looking at a small sample of the fields in this module of Microsoft Dynamics CRM there are deep functional capabilities that are available which will be able to address Field Service requirements for most applications.

However as is the case with the introduction of any new system, good analysis up front is never wasted and once the requirements and specific nuances and operational methodologies of the business are understood the configuration of the system can be planned and effectively implemented.

In my next post I will look at the scheduling aspects of this application.



Merging CRM Systems after Takeovers November 11, 2015

Posted by Ivor's Window to the IT and CRM World in Uncategorized.
Tags: , ,
add a comment


Over my career I have had considerable first-hand experience with Takeovers, Mergers and Acquisitions. Having been involved in the maze of confusion that is often apparent during these sometimes turbulent times has made me reflect on what I consider the three most important elements that need attention when dealing with the CRM (Customer Relationship Systems) as part of the merger process.

Often the priority for this is lower than it should be, with obviously ERP and Payroll being most important, however I would contend that if left for too long, this inaction could be seen as a risk to the business.

(1.) Pick the Best System

Just because you are the acquirer does not necessarily mean that you have the best system. Look very closely at the two systems and select the best of breed, what will give the best results and when looking at the data. Where is the better data and data structures housed? Running the two systems side by side in the short term is also possible, however this should be curtailed as soon as possible. You also need to consider existing integrations and how this will impact the process of replacing or switching off a system.

(2.) Migrate all the relevant data – quickly

Takeovers are often synergistic and both systems will more than likely have details relating to the same customers, which is probably the reason you purchased or took over the business in the first place. There may be a considerable amount of contact and activity data that can be very valuable when amalgamated. Data migrations are often “hard” however this is one that should be undertaken. Take the pain and then interrogate this data. You will also find a level of duplication that is often not easy to discern, where company names are spelt differently in the two systems. BNZ in one system and Bank of New Zealand in another. It is important to get this cleaned up as soon as practical.

(3.) Consider the risk of data walking away

There are often personnel casualties with mergers and takeovers, sometimes rightsizing is undertaken and sometimes people just leave of their own accord. If these are client facing people, and if they have access to the CRM system, suitable strategies need to be enacted to ensure that the data integrity is not breached and that existing customers and prospects within these systems are contacted and appraised of the situation.

Remember this data is one of the assets that you would have paid for as part of the deal.


Planning for this should be high on your agenda during the planning phase of the acquisition, and I would also suggest that even if there is a CRM system in place that has fallen into disuse and is not being used effectively, that consideration is made to evaluate this system, as the static data may well be useful.

The Origins of CRM part 2 (Sales Generator) November 25, 2014

Posted by Ivor's Window to the IT and CRM World in Uncategorized.
add a comment

It was during the summer of 1984 (30 years ago) that the seeds for our first CRM system were borne, I was working for Kalamazoo Business Systems PLC and the idea was to supplement the manual Sales Reporting System that we sold with a computer based application.
It should be remembered that at the core Kalamazoo was a printing company and the one idea behind the system was that it would consume a large amount of printing, customer record cards, Call Reports and Activity reports etc. and keep feeding the monster.

The platform that was chosen was the Pick Operating System to run on a mini computer which was part of the deal http://en.wikipedia.org/wiki/Pick_operating_system the system was built using a 4GL called System Builder. http://en.wikipedia.org/wiki/SystemBuilder/SB%2B. In 1984 this was probably deemed a very good platform decision as at the time there was little else playing in the mini-computer space apart from IBM.

For the young ones out there, have a read about Pick, it was truly innovative and Dick Pick the inventor was a very very smart guy.

Our system was based around a customer record, with the notion of Opportunity and Activities (I can’t remember if we had a contact record as a separate table). The system would print out customer record cards onto specially prepared paper and there was also some customised call report forms that reps would complete and then hand in for data capture.
We were therefore capturing all activities undertaken with the customer broken down into calls and call categories such as Appointment, Cold Call, Planned Call, and then either a Discussion Quote or Order for a list of products and a range of other metrics which we used to capture on the manual call reports, see origin of CRM part 1.

We had the system linked to the Jet Word Processor http://www.countyhistorian.com/knol/mbasj7lzroyk-41-jet-word-processor.html and we had a true mail merge capability which when coupled to the Pick TCL (Terminal Control Language) SQL for the modern types, it was possible to select all customers of a particular type with specific activities etc. and mail merge the results into customised letters, remember folks this was 1984, there are some people today who struggle to do this with all the flashy tools at their disposal. We also had a connection to an early Spreadsheet for export of data.

This was a truly innovative idea for 1984 we called it “Sales Generator” and I remember we had some very flashy presentation folders, and some top of the line printed marketing material. I cannot trace any of it on the Internet today which is a real pity.
We were geared for success, ready for action on a number of continents (Kalamazoo was a truly world-wide company) and what happened………

Not a lot

When we hit the market around the middle of 1985, our target customers being medium to large corporates with big sales teams, we immediately ran into internal computer departments in these companies, these were generally a department called Electronic Data Processing and were run and controlled by the accountants. They all told their bosses that “This is easy stuff, we can build this ourselves”. So many doors were just closed in our faces long before we even got down to talking about price. When the sales approach went through the Sales or via Management the standard reaction was to ask internally for advice, and most were buoyed by their own teams saying that they could do it in house.

We sold a few, there were some companies out there that had the vision, understood that their own computer departments would never actually come up with anything as sophisticated and bit the bullet, however supporting only a handful of customers from the UK, South Africa, Australia and New Zealand was just not possible. Kalamazoo management at the time understandably just reached a decision that the plug had to be pulled and that was that, by March 1986 it was all over, even though we as a product team had on the table a design and prototype for a PC based version that would have run on the IBM PC and compatibles of the day.

Hindsight is such a precise science and I wonder today what we could have done differently. I believe that the resistance by accountants who held the computer purse strings was underestimated by all of us, surely they would have seen the potential return on investment that additional sales would have brought! Not a chance, not in the early 1980’s. All of the customers in our target market had computer departments, and the fact that they had not provided such an application internally was also a motivating factor for many of these people to try and sell their own management on the idea that they could create their own systems. They were the trusted, we were interlopers trying to sell something radical.

No one had done anything like this before, and I can remember pitches to large boardrooms full of grey haired executives who sat there stony faced as if we were talking about science fiction, the whole concept of retrieving data from a system and automatically putting this in a spreadsheet “Visicalc” was as probably foreign to them as things could get. Why would you do a mail merge when you had a perfectly good secretary to type letters? I think we were just too early and our own board then lost the faith jumped in and stopped it too soon.

I know that we had a really good offering, it was a true B2B CRM system, I am aware that one car rental company who implemented it became so efficient that they managed to end up buying up one of their competitors, and one of the executives from a company that sold earthmoving equipment told me years later that his directorship came about due to additional sales generated by the system while he was sales manager.

The model however is still a very interesting one, sales teams updated their call reports, handed them in and someone keyed them into the system, the sales manager was presented with a set of printed reports each week showing how effective or otherwise the sales team had been, and the system produced a list of calls for each rep each week telling them where to call and what was discussed last time. Sounds a little like CRM 2015, only the people doing the data capture has changed.

Microsoft CRM Outlook Client is a game changer June 17, 2013

Posted by Ivor's Window to the IT and CRM World in Management, Microsoft CRM, Microsoft Office, Polaris, Sales Management, Uncategorized.
Tags: , ,
add a comment

Microsoft CRM Outlook Client is a game changer

It was in 2006 that I attended a Microsoft sponsored business breakfast where I first saw a demo of the then CRM 3.0 with the Outlook Client. At the time I was so very much impressed with what I saw, that the very next day I took decisive action to join a Microsoft partner just to be part of this amazing journey that I perceived was coming. it is now 7 years later and I was not wrong.

As with the demo I saw that day, today I still think that when used properly the CRM Outlook Client is fantastic and makes using CRM just so easy and very very powerful.

There are however a few things that really stand out, and recently I met with an enthusiastic user who, even though he had been using this client for two years, was unaware of some of the features, So I am going to outline my top 5 features, the first three of which this user did not even know existed.

Many of the Outlook Client features are in fact pure Outlook or even Office functions and if used correctly can enhance CRM usability.

You may need to use Outlook or CRM help if you are not sure, or look up a You Tube video, as I am not giving a click by click step through on how to use these functions. I am just outlining the basics so you can go and explore.

1.  Reading Pane Advanced Actions

Just as you can use the reading pane on your e-mail, you can use this when looking at CRM views in Outlook. Once you open a reading pane, you can scroll down the view and the data will change contextually within the reading pane. The Customize Reading Pane button is where the real power is, it will allow you to add and remove sections from the record in the reading pane, as well as being able to sort and move the order of the data around. What this actually means is that you are able to build a view of a CRM form that is totally different to the view you would see when you open the record.

2. Quick Access Toolbar

This is a standard Office function that few people use, and if used with CRM it in effect allows you to have access to CRM items with one click from anywhere in Outlook. Right mouse click in free space on the ribbon and select the Customise Quick Access Toolbar. Once it is switched on, either above or below your ribbon you can then go to other areas of CRM and select menu items with a right mouse click and add them to the toolbar. I have accounts, contacts and leads on mine and no matter where I am in Outlook I can with one click create a new record. Obviously you can use this for standard Outlook and Office functionality as well.

If you add the CRM record icon to this view, you get the dropdown for all CRM Records. If you have everything that you use regularly, you can close the ribbon and get some more screen real estate.

3. Recent Visited Records

When you go to the left navigation pane of Outlook and look at CRM entities, if you right click once on any of these items, you will see a Recently Visited option, this then shows the recent records that you have viewed. This is a really fast way to navigate to those recent records.

This also works on custom entities and is very useful.

4. Conditional Formatting and Categories

This is one of my all-time favourite options. This is standard Outlook functionality, which if used correctly will allow you change the formatting of different views, and when working in tandem with Categories (you can make the colour of different rows within the view different based on the category or categories that you have added to the view). This really has a powerful application in CRM, in that it is easy to highlight information.

You need to go to a view, select the View Options and then Conditional Formatting. It is not quite as extensive as the condition formatting in Excel, but comes a good close second.

5. Filter

For those of you familiar with the Excel Filter, this is a similar tool and allows you the capability of looking at views of CRM Data that are filtered. Just click on the Filter button and you are away. As with Conditional Formatting it also works on custom entities.

It is not a ribbon button but is found at the top of the view, hence a few people miss it, however once you use it you can have your filtered records on screen with a customised reading pane and conditional formatting giving you a fantastic view of your data all with real context.

Give it a try I Dare you.

The Origins of CRM Part 1 – Call Reporting April 23, 2013

Posted by Ivor's Window to the IT and CRM World in Management, Microsoft CRM, Sales Management, Training, Uncategorized.
Tags: , ,
1 comment so far

The Origins of CRM, Early Days, Part 1 Call Reporting

I am very fortunate to have been involved right in the beginning of the computer based CRM industry. I was working for Kalamazoo Business Systems PLC in the early 1980’s before the introduction of MS Dos and when the concept of the Personal Computer was really in its infancy. Most companies had large mainframe systems or what was termed mini computers, however no one was doing anything that looked like CRM on these computers at that time. Many companies still ran manual systems for Accounting, Payroll and Cash Book.

Kalamazoo also had a manual Sales Reporting System which had remained unchanged from the mid 1960’s and I was given the task of giving this product a total overhaul as the precursor for the computer based sales management system we were planning. Principally this manual system had a number of quite interesting components, with the main selling objectives being:

  • A system to aid in the retention of customers.
  • The capability of monitoring of salespeople and their activities.
  • Something that was easy to use, and thus no extra work for the sales staff
  • Giving management some basic control and visibility of information over what the external sales teams were doing.

Sounds a little like modern CRM doesn’t it?

The way it worked was as follows: Each sales person was given a ring binder with a set of customer cards, just imagine an A5 card divided into two sections, the top section had all of the customer static information, name, address phone number etc. and the bottom section had a set of ruled horizontal lines each denoting an individual appointment or call made on the customer.

The sales person was also given a special clipboard onto which a daily call report was placed. This board had a series of pegs on the left hand side. This A4 form had the same ruled lines that were found on the customer card.

The sales person would make the call, and then remove the customer card from the binder, place it on the clipboard and update one of those single lines for the appointment. This card used carbonised paper, and therefore whatever was written on the customer record appeared on the call report. The sales person could then go onto the next call and by just lining the next card up on the next blank line on the report was able to do his work and the by product was a call report that was handed in. (see the link below)

Some of the changes that I introduced through the judicious use of form design meant it was possible to create a manual report that would give considerable management information and by ticking boxes on the customer record card, and selecting options from a key, it was possible from a single A4 report with 22 calls on it to determine many metrics just by looking at the form.

For example (See attached Image of a Call Report from 1984 from which the following can be derived).

  1. Brief Call Report. Only pertinent facts, no long stories (these can be transferred to the Action Request if necessary).

2. Time Utilisation. See how the salesperson used his time when there was a broken appointment.

3. New Business. After a broken appointment see if the salesperson was prospecting.

4. Action Request. Via the action request which is a short memo form, other departments can be notified as to actions that they must undertake. The salesperson keeps a copy and files with customer record card.

5. – 10  Call Analysis.

  • Is the salespersons activity above or below the national average, how does he compare?
  • What is the call to order ratio?
  • How many broken appointments?
  • No activity on product F, why?
  • Were there enough new prospect calls?
  • Which competition did I run into the most?
  • What is the discussion to order ratio?
  • Is the spread of market sector calls proportionate to orders?
  • How many action requests and queries?
  • How many quotes to orders?

11. Order Value. This is only for orders picked up by the salesperson, how does this compare to the phoned in orders?

12. Follow up Dates. These dates make for pre-planned calls. Transferred immediately to the new call report sheet to act as a diary. New staff would have a ready-made list of calls to be made, maintaining continuity.

13. Monitoring Opposition. For example in 22 calls, ran into opposition number 2 six times, and others only once or twice. Is there a trend here?

14. Detailed Product Analysis. Can indicate good and bad lines. Are sales people not discussing any particular products?

See Call Report here.


When this data was entered into the VisiCalc Spreadsheet that I designed, management were able to get a consolidation of this information by sales person, team and office. This was ultimate Business Intelligence for sales people in 1983. Although it is possible to get exactly all of this from a new Microsoft CRM Sales Implementation, I don’t believe that many sales organisations actually go this far in 2013. Remember folks that this was 30 years ago. The key lesson here is that if you are able to capture information you will be able to use it, sales people are often the eyes and ears of the organisation, and as in the example above, if the sales person runs into competitor number 2 that many times, it would only become apparent if the information was recorded with the correct context.

It should be remembered that conceptually a CRM system in those days would not have involved the sales and marketing teams entering data themselves, this would be captured on manual reports and forms and entered into the system by a data capture clerk.

There will be more blogs to come on some of the other manual systems that were used and the computer based CRM system “Sales Generator” that we launched in 1985.


Do you really need that field? February 11, 2013

Posted by Ivor's Window to the IT and CRM World in Microsoft CRM, Uncategorized.
Tags: , , ,
add a comment

Do you really need that field?

A customer asked me to include a field to record Golf Handicap on the CRM Contact record as it was thought this would be a good idea to assist when searching for their customers to attend Golf Days.

After asking some questions I discovered that they held one golf day per year where they sponsored a single hole, and that 50% of the sales reps were women with no knowledge or interest in golf. This field would just not get updated and unless the sales team were following each of the customers who did play golf it is unlikely that those with a handicap would get updated when the handicap changed each time.

The point of this all is that the flexibility offered in Microsoft Dynamics CRM where fields can be created and deployed within minutes gives the person configuring the system considerable power. Weak consultants get caught up in the hype of the “let’s define fields workshop” and away they go creating fields all over the application, which never get used.

To quote Voltaire the saying “With great power, comes great responsibility” should equally be applied to CRM consultants who should be responsible when defining new fields as part of the analysis for a CRM system.

The fact that you can do it, does not necessarily mean that you should do it.

This is blog number 2 in the series “The more things change, the more they stay the same”

Test Post May 14, 2011

Posted by Ivor's Window to the IT and CRM World in Uncategorized.
add a comment
Microsoft Dynamics CRM

Everything CRM and other cool stuff

Microsoft Dynamics 365 Team blog

Everything CRM and other cool stuff

Hosk's Dynamic CRM Blog

All views and opinions are personal opinions of the Hosk