myCRM 9.2

User Guide

Serenaware.com

All Rights Reserved

TABLE OF CONTENTS

Introduction                                                     

Application structure                                        

Customers                                                       

Opportunities                                                   

Sales                                                               

Display filters                                                   

Principals                                                         

The Selection Mode                                          

Activities                                                          

The Diary                                                         

Geocoding Customers And Area Management    

Relationship Management                                 

Sending Emails to Customers                           

Database Backup And Restore                  

Data Export                                                              

Import Customers                                            

License Management and Price List                   

INTRODUCTION

MyCRM is an application designed for all professionals engaged in sale or business activities.

MyCRM is useful in situations where the professionals work mostly in mobility and need constantly to have at hand the "snapshot" of their business.

The application manages the entities involved in the sale process, which are: customers, opportunities and sales. There are also some other auxiliary entities, which are: activities, events and engagements in diary, principals, areas and relationships.

In the next chapters we will look at them in detail together with their links.

APPLICATION STRUCTURE

The application uses an internal database that contains all the data entered by the user. The database is stored entirely in the device and, therefore, the application does not need an internet connection to read it. Nevertheless, there are some operations that can be done only when there is an internet connection. These are:

• backup/restore of the database on Google Docs
• Import data from a Google Docs spreadsheet
• Geocoding and display of customers on maps

Therefore, the presence of an internet connection while using the application is recommended but not required.

In order to be used, the application needs a license level. This can be purchased from inside the application through the “license management” section. Initially, at the moment of installation, the application is provided with the basic free license level named “FREE10REC” that allows you to freely use all functionalities of the application, but doesn’t allow you to insert more than 10 records for each entity. With upper license levels you can increase that threshold up to make it unlimited.

Most of the operations carried out by the application consists of reading data from the database. The read data are then represented either with list views or with detail views. Both types of views have a "Menu" button. In the list view menu (also called list menu) all entries that launch operations on existing data refer to the data contained in the list itself, whereas in detail view menus (also called contextual menus) entries refer to the data record contained in the view itself.

List menus are marked with the symbol ▤ whereas contectual menus are marked with ▼.

The main detail views have a dual display modes: form mode and plain mode. These are two different ways to view the same data, coming from the same database record. The form display mode includes all data in their fields and includes near them a descriptive label. The plain display mode, instead, writes all data in an easily and readable format, as if they were written on a sheet of paper. The form display mode is required when you enter or change data, whereas the plain display mode is particularly indicated when you consult the data.

The navigation among data is slightly different depending on whether the device is an iPhone/iPod Touch or an iPad.

With the iPhone/iPod Touch, you proceed always by accumulating a view over the other and then going back. Eg. If you want to perform an operation on a certain customer, you should first open a view that is the main menu, then you overlap the customer list. In there, choosing a customer, you overlap the detail view of the customer and eventually the contextual menu. In order to return to the main menu, you must browse the "stack" of views in reverse order, or make a shaking of the device (whose sensitivity can be adjusted in the "Settings").

On the other hand, in the iPad the interface is always divided into two parts: a list on the left and a detail view on the right. The list on the left is always visible when the iPad is placed in landscape mode. When the iPad is placed in portrait mode, the list is hidden, though viewable through the button "Show".

Therefore, when you proceed in the navigation of data, the accumulation of the views happens in a separate way: all list views are accumulated in the list on the left, while all the detail views are accumulated in the right area. Both sections of the application are equipped with specific buttons to "go back" from the accumulation of views. Nevertheless, the application will automatically remove the accumulation of left and right views whenever needed.

the elimination of the items is common to all lists. To delete an item from the list, simply swipe your finger on the item itself from right to left or vice versa, and then press the red confirmation button that appears over it.

The lists on the main entities, namely Customer, Opportunities and Sales, are subject to pagination and can be filtered. The pagination is a way to show the list not entirely, but in groups of N items, where N is a parameter that you can set in “Settings”. The pagination allows management of lists of any length (with the sole limitation imposed by the exhaustion of disk space on your device) without overloading the application. The size N of the page should be adapted by the user to the power of your device. For the latest devices, in general, you can use high values ​​of N, while a low value is recommended for the older devices.

The ability to filter lists, instead, consists of allowing the user to choose a display filter among the many available or make a textual search. (This topic will be developed in details further on). You just have to remember here how the result of applying one or more filters is a list whose number of elements is reduced compared to the total. All the items in the list menu that operate on existing data will apply to this reduced list.

MyCRM defines a public folder you can access to through iTunes according to the standard made ​​available by Apple. In this folder different types of files are stored, for reasons that will be cleared later on.

Therefore, over time the folder will be filling up more and more. This leads to two consequences: the decrease of the free disk space of the device and the increase of the synchronization and backup times through iTunes.

It is therefore important that the user is always aware of what and how many files are contained in this folder. It is also important that the folder is emptied from time to time (all or in part) whenever its content is no longer useful.

To access the public folder of myCRM you must:

1.   connect the device to your PC/Mac

2.   launch iTunes on PC/Mac

3.   select the device from within iTunes

4.   Select the "App" view

5.   scroll the view to the bottom, up to the "Document Sharing" section

6.   select the icon of myCRM

After this, the right pane will display all the documents in myCRM public folder. From there, the user is able to copy them on its pc/mac, delete them, or insert new ones taking them from its pc/mac.

A first use of the public folder is to contain the logging file. Logging is a system that tracks operations made by the application from time to time. It serves only to identify problems or application errors ("debugging"). The activation of the logging is done by turning on the proper switch into the "Settings" view (menu "Utilities").

We recommend turning on logging system only if specifically requested by Serenaware Support, because it has no utility in the normal use of the application, and might slow down performances.

When logging is active, it generates two files, called mycrm.1.log and mycrm.2.log, the latter being not always present, stored precisely inside the public folder. In case of any problems and/or if required by Serenaware Support, the user will have to retrieve those files from public folder and send them to Support via email.

In some cases, the application itself realizes that there have been a problem (a "crash") and offers automatic email sending of these files.

Please consider that, regardless of the mode of transmission of these log files, they can contain (in whole or in part) the data that you have entered in the database. These data can be read by Serenaware, which, however, is committed to strict confidentiality and non-disclosure them to third parties.

A second case of use of the public folder by myCRM is when, in very exceptional circumstances, the application generates a "fatal error". Cases like these may be caused by a corruption of the database and therefore, in case of fatal error, the application makes a copy of the entire database and stores it in the public folder with the name mycrm.db.corrupted or mycrm.db.corrupted.<n>, where n is a sequential number introduced in case more than one corrupted db file exists into the public folder, to avoid overwriting it.

In such cases, you should contact Serenaware Support and send the generated file.

CUSTOMERS

The entity “customers” is the main entity of the application. You can access it from the main menu at the item “Customers”.

In this section you can:

• Create a new customer
• View, edit or delete an already registered customer
• View lists of customers by using various display criteria
• export, show on map, associate tags, define relationships, perform statistical calculations, etc..

Creating a new customer

You can record all customers, either actual or potential ones of your business. You can record various information for each customer, the main of them being obviously the name.

There are two types of customers: "simple contacts" and "companies"

The "simple contact" customer represents a single person or company, while the "company" customer represents a company or, more generally, an organization constituted by one or more simple contacts. The "company" customer therefore has a dual nature: on the one hand, it is itself an effective customer to which, for example, you can assign a task or an opportunity; on the other hand, it represents the set of its simple contacts and therefore the actions performed on it will act on the entire set of those contacts. For example, if you need the list of opportunities associated with a "company" customer, the generated list will report both the opportunities directly associated with it and the opportunities associated with each of its simple contacts.

When you insert a customer, you must always specify its type. If this is a "simple contact", then you have the ability to associate the customer to an already existing "company" customer. This association, however, is not mandatory. Therefore, a "simple contact" customer may or may not belong to a company, but if it belongs to a company, this latter will be unique, i.e., a simple contact is not allowed to belong simultaneously to several companies.

The name is a unique and obligatory field. It may contain any text that identifies the customer, for example, the name of the customer or the name of her/his business or a combination of the contact and company names. There is great freedom in this, but we suggest to adopt the same format for all records. For example:

• <first name> <surname>
• <surname> <first name>
• <first name> <surname> - <company>
• <surname> <first name> - <company>
• <company> - <first name> <surname>
• <company> - <surname> <first name>
• etc.

If you want to work with "company" customers, it is advisable not to include the company name into the name of the simple contacts owned by the company.

In addition to the name, you can then associate to the customer other information, that are: codes, addresses, phone numbers, fax numbers, email addresses.

The app allows you to insert more than one value for each of them. For example, regarding the phone numbers, you could enter either a mobile phone number, or a home phone number, or an office phone, etc; regarding the codes, you could enter a value for the VAT number, another for the fiscal code, another one for the matriculation, etc.

Therefore, these are information that require the insertion of any number of “type-value” pairs. That is, for each value you add, you have also to assign a "type", representing a brief description. For example, the phone number could have the following pairs "type / value”:

• Type: "Mobile";    value: “+39.333.123.45.67”
• Type: "Office";     value: “+39.06.987.654.32”
• Type: "Home";     value: “+39.02.345.678.89”

The user will then have to identify one, by setting the checkmark on the right side out of all inserted "type/value" pairs, that will represent the value displayed in the summary screen of the customer.

Eventually, the app provides a residual “notes” field into which you can insert any type of descriptive information.

Viewing lists of customers

Entering the section “Customers” you will see the list of customers registered in the application. Initially, this list is populated with all customers present in the database. However, you can restrict the list to specific subsets of records either by applying a display filter or by making a textual search on the name field (see below).

Once you have obtained the list of customers, you can make some operations on it.

First of all, you can select a customer: you will display its detail view, in read only mode. Then you can change to editing mode or open the contextual menu that provides further operations to perform on the single customer.

From the customer list you can then delete one single customer by swiping the finger from left to right or vice versa and pressing the red confirmation button.

Eventually, always from the customer list, you can perform further operations like entering in selection mode, showing the list on the map or exporting the list. These operations will be described in detail later.

Special dates

Starting from the customer detail view you can access the section of the “special dates” through the contextual menu.

The “special dates” are dates linked to the customer, e.g. the birthday that you want to jot down in the diary. You can associate any number of special dates to each customer.

You can insert the special date in a complete format, i.e. day, month and year or you can insert only the day and the month ignoring the year. The latter case serves when, for example, you know the day and month of birth but you don't know his birth year.

After having inserted the special date, you can associate a description and set the ways it will be jotted down in the diary. The date can be jotted down in the diary in exact way (but only if the special date was inserted in the complete format) or with a monthly or yearly periodicity, starting from the moment of its registration. In case of the periodical annotations, they will be repeated in the diary for a finite time period, which is set by the user (3 years as default).

The “special date” is a specific type of “event”. The events, as well as the “engagements”, are auxiliary entities managed through the diary.

Customer history

From the customer detail view you can open the customer history. This consists of the list of all events and engagements on the diary sorted by increasing date that are related directly or indirectly to the customer. Eg. it will show all past and future engagements related to pro-customer activities (see below) and to pre and post sale activities related to opportunities and sales linked to the customer. You will also see all the engagements related to the "special dates" and events such as sale dates, dates of insertion/update of opportunities, etc. Eventually, you will see all the events on the diary generated by the relationships maintained with the customer (see below).

The customer history, therefore, is a powerful tool to immediately resume the awareness of all the work done for the customer, all the held interactions and all the potential or actual business generated from him.

Categorization by "tags"

You can associate a customer with any number of "tags". Tags are simple labels created by the user to which he associates a meaning. All customers associated with the same tag are part of a same category and they can be extracted and displayed by using appropriate display filters (see below).

Through the definition of tags and their association with customers, you can create any number of categories of customers and these can be completely separated by each other (i.e. customers belonging to one category do not belong to the other one) or even partially or totally overlapped (i.e. some or all customers belonging to one category can belong to the other one), according to a logic dictated exclusively by the user, according to his personal use of the application.

Export of customers to the device’s address book

Every device, iPhone/iPad, has its Contacts application that allows you to manage an internal phone book of names. You can import all or only some of these names in myCRM. This process will be described later, in the chapter dedicated to the import of customers. However, the reverse process is also possible, i.e. exporting a myCRM customer toward the device’s address book. This can be done both during insertion of the customer, and afterwards.

During the insertion phase, you must set to ON the "Create also in Contacts" switch present in the input mask of the customer. However, if the customer has already been created, you can select the item "Add to Contacts..." in its contextual menu.

For both operations, it should be noted that the passage of the customer from myCRM to Contacts has some limitations due to the different model of data representation that the two applications use. The limitations are the following:

• it is not possible to differentiate the first and the last name of the customer. MyCRM adopts, in fact, a single field for entering the name while Contacts uses two fields, the First and Last name. Therefore all the content of the name field of myCRM will be "transferred" in the first name field of Contacts, while the last name field will remain empty.
• It is not possible to differentiate the various parts which make up the addresses. In fact, myCRM adopts a single field to store an address, while Contacts adopts various fields, that are street, city, state, zip, county, etc.. Also in this case, therefore, the address will be "transferred" in the first field "street", while all other fields will remain empty.
• The Contacts application does not include the Fax field. Therefore, when transferring the customer from myCRM to Contacts all the fax numbers will be inserted into the phone list together with specific labels highlighting the fact that the number is a fax.
• Codes and Tags are not exported. The customer form of the Contacts application, in fact, does not provide this kind of fields to accommodate this data.

In addition to the above mentioned limitations you should consider that during the creation of a myCRM customer and simultaneous creation of the customer in the address book of Contacts, there is no control over the existence of the same customer. Therefore, if the name already exists, a duplicate will be created.

On the contrary, if you first create the customer only in myCRM and then you export it through the action "Add to Contacts...", then you will be asked to take one of these two actions:

1.   Create a new customer into the address book of Contacts that will contain all the data of the original myCRM customer.

2.   Add the data of the original myCRM customer to an already existing customer of the Contacts address book. In that case, the user will have to scroll through the phonebook in search of the name that will have to "accommodate" the myCRM customer data. Once it is chosen, the data will be added to those already present in it.

OPPORTUNITIES

The opportunity collects any data related to the situation that occurs when the user has the perception there is a chance to make an actual sale or finalize a deal for a particular customer.

The opportunity, therefore, is not a real event in the work life of the professional, but a potential event, to which a certain probability of occurrence is associated.

You can access to the “Opportunities” entity from the main menu under the item “Opportunities”.

In this section you can:

• Create a new opportunity
• View, edit or delete an already registered opportunity
• View lists of opportunities by using various display criteria
• Export the above lists, perform statistical calculations

Creating a new opportunity

An opportunity is always linked to one and just one single customer. Therefore, during its creation you must always choose, through the proper field, an existing customer or create a new one contextually.

The other information to associate to the opportunity are:

• The object, that is a short description of what the opportunity is, ie: "Two-year supply contract.";
• The insertion date, that is, the date on which the opportunity is recorded. This date will be reported in diary.
• the (supposed) date of the end of the opportunity. This date will be reported in diary.
• The principal (see below) to which the opportunity is linked.
• The value (expressed in the currency selected on the device), which represents the total value of the sale or the deal.
• The commission that the seller receives if the sale was successful
• The probability of realization of the opportunity;
• The status of the opportunity. Its selection also automatically updates the value of probability of realization. The possible values are:
  • New (prob. 25%, modifiable by the user)
  • In progress (prob. 50%, modifiable by the user)
  • In negotiation (prob. 75%, modifiable by the user)
  • Closed WON (prob. 100%, not modifiable by the user)
  • Closed LOST (prob. 0%, not modifiable by the user)
• Any notes

Among the values the status of the opportunity can assume, there are two particularly important ones. They are "closed WON" and "closed LOST”: they will be explained in detail.

Positively closed opportunity (“WON”)

It indicates that the opportunity has actually resulted in a sale. By saving the opportunity in this state, you will automatically generate a record in the sales section. This record receives all the opportunity data and then it becomes completely autonomous from it. This means that the sale record can then be modified as desired without affecting the opportunity record. This latter remains "frozen" with the values it had when it was positively closed.

When saving a positively closed opportunity, you are asked for some additional data that will populate the sale record. Those data are: the discount applied to the customer, the method of payment and the number of installments.

Negatively closed opportunity (“LOST”)

It indicates that the opportunity has been permanently set aside or, in other words, that the chances of its success are dropped down to zero.

The user can change at any time the status of the opportunity, starting from any other status. However, we point out how the transition from a "closed WON" to any other status has the side effect of eliminating the related sale record that was originally generated at the positive closure of the opportunity. This removal will cause the deletion of anything else associated with that record, such as all the activities and engagements.

Viewing lists of opportunities

By entering in the section “Opportunities”, you will see the list of opportunities registered in the application. Initially, this list is populated with all opportunities present in the database. However, you can restrict the list to specific subsets of records by applying one of the many available display filters (see below).

Once you have obtained that list, you can make some operations on it. First of all, you can select an opportunity. By doing this, you will display its detail view, in read-only mode. From here, you can switch to editing mode or open the contextual menu that provides further operations to perform on the single opportunity.

Moreover, you can delete one single record by swiping the finger from left to right or vice versa and pressing the red confirmation button.

Eventually, still starting from the opportunities list, you can perform further operations like entering in selection mode or exporting the list. These operations will be described in further details below.

SALES

As we mentioned above, the sale records represent the actual sales from which normally commissions derive.

Typically a new sale is generated automatically by the application when a pre-existing opportunity is positively closed. However, you can also create new sales directly, without any link with opportunities.

You can access to the “Sales” entity from the main menu at the item “Sales”.

In this section you can:

• Create a new sale
• View, edit or delete an already registered sale
• View lists of sales by using various display criteria
• Export the above lists, perform statistical calculations

A sale is always linked to one and just one single customer. Therefore, during its creation you must always choose through the proper field an existing customer or create a new one contextually.

The other pieces of information to associate to the sale are:

• The object of sale (it is borrowed from the record of the related opportunity, if it already exists);
• The customer (it is borrowed from the record of the related opportunity, if it already exists);
• The date on which the sale was made; it is preset as the date of creation of the record;
• The principal (see below) to which the sale is linked.
• The value of the sale (it is borrowed from the record of the related opportunity, if it already exists);
• The percentage of discount applied to the customer in respect to the total value of sales;
• The actual amount of the sale; the value is calculated (automatically) by applying the discount to the value of sales
• The percentage of sales commission;
• The amount of commission, in absolute terms; the value of this amount is automatically calculated by the application when the value of the percentage of the sales commission is bigger than zero. On the contrary, when the percentage is zero, the field becomes editable by the user which can then insert any value (but still below the total value of the sale). In this way, the user has the ability to enter fixed values for the commission ​​or values that vary in an unconventional way compared to the value of the sale.
• The payment modes;
• The number of installments in which the payment is made;
• Additional notes

Viewing lists of sales

By entering in the “Sales” section, you will see the list of sales registered in the application. Initially, this list is populated with all sales which are present in the database. However, you can restrict the list to specific subsets of records by applying one of the many available display filters (see below).

Once you have obtained that list, you can make on it some operations.

First of all, you can select a sale. By doing this, you will display its detail view, in read-only mode. From here, you can switch to editing mode or open the contextual menu that provides further operations to perform on the single sale.

Furthermore, you can delete one single record by swiping the finger from left to right or vice versa and pressing the red confirmation button.

Eventually, always from the sales list, you can perform further operations like entering in selection mode or exporting the list. All these operations will be described in detail below.

DISPLAY FILTERS

The lists of customers, sales and opportunities may be restricted by applying display filters. To do this, open the menu of the list and click on "Display Filter...". This will open a special panel through which the user can choose one of the many available filters and combine them into more complex boolean expressions.

In the upper part of the panel, a pane shows the current filter. The text in the box will be updated automatically as the user selects and combines the filters.

In the central part of the panel, there is a selection filter field. By using the button to the right of the field, the user can open the list of all available filters and select one of them. For filters without parameter, this selection will determine the update of the current filter written in the top pane. On the contrary, for filters with parameter it will be necessary to select also the value of the parameter before the filter is updated.

Filters can also be combined according to the "boolean" logic. To do this, there are some small buttons at the bottom of the panel. These are:

• logic "OR" (+): it allows to put in "or" two filters (the one on the right and the one on the left of the symbol). In this case, the resulting list will contain both the records extracted by the first filter and those extracted by the second filter.
• logic "AND" (&): it allows to put in "and" two filters (the one on the right and the one on the left of the symbol). In this case, the resulting list will contain only the records simultaneously extracted by both the first and the second filter.
• Logic “NOT” (!): it allows to make the logical "not" of a filter (the one on the right side of the symbol). In this case, the list will contain all records that would not be extracted from the filter.
• "parenthesis" button: it is used to enter the parentheses in the boolean expression that you are creating. You can include only one level of parentheses, therefore, once you enter an open parenthesis, you can then enter only a closing parenthesis. Therefore, the button will automatically show the symbol of the parenthesis, open or closed, which can be inserted.
• “undo” button ( <X] ): it allows to delete the last inserted element from the expression you are creating, be it a filter, or a logical symbol or a parenthesis.
• “clear” button ( [X] ): it allows to delete the entire expression entered so far and to restore the default filter "all".

Therefore, in order to create a complex expression the user will have to proceed by turns, by choosing a filter (with any parameter attached), a Boolean symbol or a bracket. If you attempt to insert one of these items in a syntactically wrong manner, the item itself will not be included.

The panel of display filters also allows choosing the sort order of the list in its lower part. The user can choose either the field according to which the order will be made, or the order direction, that is ascending or descending.

Textual searches in the customer list

Besides providing the ability to apply display filters, the customer list also allows textual researches. At the top of the list there is in fact a field where the user can enter the text to search. Immediately below that field there is a list of buttons horizontally scrollable with the finger. Each of these buttons represents one of the fields that make up the customer form. If you select the "name" button, for instance, you will have the effect to search text within the name field.

On the extreme right of the list of buttons there are also the options with which the text search is carried out. These are:

• whole word: it means that the search text must match whole words.
• contains: it means that the search text can also be contained within individual words.
• ignore case: it means that the search must be case insensitive.
• consider case: it means that the search must be case sensitive.

The selected options are the visible ones. To change the choice, just tap with your finger the same options that will change accordingly.

The rules to consider for textual searches are the following:

• The text entered will be searched only within the field selected in the list of buttons and according to the rules imposed by the search options;
• if the entered text is a single alphabetic character (not numeric) every customer will be extracted who has a value that begins with that letter in the field selected in the list of buttons;
• The textual search executes an additional filter over the one already applied. Therefore, it further reduces the result set generated by the display filter. If you make more textual researches, one after the other, they will act all on the same display filter and do not accumulate one over the other.
• To remove a textual search you have to start to edit the search field and then press the "Cancel" button on its right.

Extraction of “neighbouring” customers

Among the available filters for the customer list, there is one called "those within range X". This filter allows extracting all the customers whose position is within an area of ​​radius X centered on the current position of the device. This filter therefore lets you know instantly all customers that are in the neighbourhood while you are moving on the territory.

However, in order for the filter to be effective, it is necessary that all customers have been already geocoded (see below). We suggest, therefore, launching a manual geocoding (“Main Menu” => “Utilities” => “Geocoding customers”) before starting to use this filter.

The filter remembers the current position for 10 minutes, then discards it. Therefore, if after 10 minutes the device has moved for a considerable distance (eg. you are in a car in motion) it is advisable to reapply the filter so that it can return updated results.

PRINCIPALS

An opportunity or a sale may be associated, at creation time, to a principal.

The principal can be created either during the above mentioned association or through the menu "Other entities" => "Principals" => "Create new principal".

The pieces of information that may be included are:

• Name of the principal (mandatory)
• Maximum discount: maximum percentage of discount allowed by the principal
• Suggested discount: percentage of discount suggested by the principal
• Maximum commission: maximum percentage of commission applied by the principal
• Standard commission: standard percentage of commission applied by the principal
• Allowed payment methods: set of allowed payment methods allowed by the principal
• Maximum n° of installments: maximum number of installments allowed by the principal
• Notes: additional notes

When a principal is associated with an opportunity, the value of the "commission (%)" is automatically filled with the standard value of the commission provided by the principal. The user can change this value, but he will not be able to enter values above the maximum commission provided by the principal.

Similarly, when a principal is associated with a sale or when a sale is created starting from a won opportunity linked to a principal, the values of the fields "discount (%)" and "commission (%)" will be filled with the suggested discount and the standard commission provided by the principal respectively. The user can change, then, these values, but he can never exceed the values, respectively, of the maximum discount and the maximum commission provided by the principal.

If the principal provides fixed commissions or commissions that vary in an unconventional way with the value of the sale, then you can enter the zero value in the "maximum commission" and "standard commission" fields. In this way, you will make the "commission amount" field of the sale editable, thus allowing the insertion of fixed values in it, ​at your own will.

Eventually, the payment methods and the maximum number of installments will be limited in their values to those provided by the principal. Therefore, the user will have the possibility to choose a payment method among those provided by the principal and to choose a number of installments not exceeding the maximum number provided by the principal.

The association of the opportunities and sales to principals allows the use of specific display filter that extracts all records related to a particular principal.

THE SELECTION MODE

For the three main entities, that is Customers, Opportunities and Sales (but also for other secondary entities such as the Relationships) you can use the selection mode during the display of the lists of records in order to make operations on the set of selected records.

To use the selection mode you just need to select the “Start selection” item in the list menu. When you have done this, the list “enters” in the selection mode. In this mode, the selected items will change their color and a check mark will appear on the left. In this manner you will be able to select all records you want. Then, by opening again the list menu, you will see all the allowed operations for the selected records (as well as other general operations).

For example, you will be able to make multiple deletions of records or, in the case of the customer list, make the multiple creations of opportunities on the selected customers.

Eventually, to exit from the selection mode, you will just need to select the “End selection” item in the list menu.

ACTIVITIES

Each of the main entities described above, namely Customers, Sales and Opportunities, one or more "activities" can be associated. A record of activity represents a collection of information that describes an activity to be carried out by the user.

The activity is a concept relative to the future. This is opposed to the "relationship", which will be described later on, which refers to the past.

There are various types of activities, which are:

• "pro-customer" activities: they are activities related to a single customer. They are created and listed through the contextual menu of the customer;
• "multi-customer" activities: they are activities related to more than one customer. They are created from the customer list menu and listed under the diary list menu;
• "pre-sale" activities: they are activities related to a sales opportunity. They are created and listed through the contextual menu of the opportunity;
• "post-sale" activities: they are activities related to a sale already made. They are created and listed through the contextual menu of the sale;
• "generic" activities: they are activities linked to no entity. They are created and listed through the diary list menu;

An activity is described by the following information:

• Title: it is a brief description of what is an activity;
• Description: contains the full description of the activity;
• Date: it is the date on which the activity must be done;
• Time: it is the hour at which the activity must be done;

NOTE: The date and time should always represent a future point in time in comparison with the moment in which the activity is recorded. This is because this entity has been designed to track things "to do" with a customer, with opportunities etc. However, for a greater flexibility in using the application, you can also enter past points in time. This is particularly useful when defining periodic activities.

• Frequency: it is the type of periodicity of the activity. Possible values are:

o      “Una tantum” (that is, single)

o      Daily, weekly, monthly, three-monthly, half-yearly, yearly

o      At Every 5, 10, 15, 20 45, 60 days

When "una tantum", the activity will be made in one shot at the date and time set into the "date" and “time” fields. In all other cases, the activity will be periodic, starting from the date set into the "date" field and with intervals set by the value of the "frequency" field, for example, daily, weekly, etc.

• Up to: the deadline beyond which the periodic activity (that is, not "una tantum") must terminate;
• notice dd: it represents how many days before an activity starts you would like to display a warning in the diary (if you have enabled the synchronization with the device calendar, this field has no meaning and is replaced by the definition of the "alarms", as described later on);
• Constraint: indicates which criterion should be followed when you calculate all the engagements of a periodic activity. Possible values are:

• exactly at the date
• not in the weekends

The value "exactly at the date" means any day in which the engagement is, this will be set in the diary, while the other value "not in the weekends" specifies that if the engagement falls on the weekend (Saturday or Sunday) it will be anticipated to the Friday before the weekend.

When an activity is saved, the application automatically inserts in the diary all the engagements deriving from it. In particular, for a "una-tantum" activity, only one engagement will be set in the diary, whereas for a periodic activity, more than one engagement will be generally set in the diary.

Appointments

MyCRM manages the concept of “appointment” as a special case of activity. In particular, the appointment is nothing else than an activity with a "una tantum" frequency that, at the time of its creation, must refer to a future point in time.

Appointments must be related to an entity. So, we have appointments with customers (pro-customer activities), appointments for opportunities (pre-sales activities) and appointments for sales (post-sales activities).

During creation of an appointment, the application automatically inserts some detailed information in the "object" and "description" fields. On the diary, the appointment appears with a specific color.

Multi-customer activities

This type of activity is always linked to more than one customer. To create such an activity, you have to first go to the customer list and apply a filter or manually select a certain set of customers. Then, from the customer list menu, by selecting "create new activity...", you proceed with the definition of the data of the multi-customer activity. This latter, if saved, will be linked forever to the customers of the list (or the manually selected ones).

The association of the customers to the multi-customer activity is therefore defined when creating the activity and cannot be changed anymore. However, there is an exception: that is, when one of the customers involved in the multi-customer activity is completely removed from the database. In this case, the list of customers involved is reduced by that customer. If after this reduction only one customer remains in the residual list, then the activity is automatically transformed into a "pro-customer" activity and linked to that residual customer.

The multi-customer activities are listed through the list menu of the diary. By selecting one of them and opening its detail, then, you can see, through the contextual menu, the entire list of customers involved.

THE DIARY

Within myCRM there is the diary which is accessed from the main menu "Diary" item.

Diary consists of three views: a daily, a weekly and a monthly one. The purpose of the diary is to display on a calendar all the activities defined by the user, as well as all other types of events defined in myCRM such as the special dates of customers, the relationship events, the appointments, the memos, etc.

Every single item present in the diary is called "engagement" in diary, if it is directly linked to an activity, or, more in general, “event” in diary, if it is linked to other types of events generated by myCRM.

The diary allow the simultaneous display of all engagements/events or even a filtered view of the same ones by category. The filtering is performed by acting on the horizontal bar of the categories present in the header of the diary. The categories are:

• all: any engagement/event is displayed
• activities: only the engagements related to the activities of any kind, but which are not appointments, are displayed
• appointments: only the engagements specific to appointments are displayed
• special dates: only the events related to the special dates are displayed
• opportunities: only the events related to the opportunities are displayed, ie, insertion, updating and end of opportunities
• sales: only the events related to the date of sale are displayed
• relationships: only relationships events are displayed
• memo: only diary memos are displayed
• done: any engagement/event whose status is "done" is displayed
• not done: any engagement/event whose status is "not done" is displayed

The engagements/events can never be directly generated by the user, but they are generated automatically by the application when the user defines an activity (periodic or not) or when he defines other types of events such as the special dates of customers or the date of presumed end of an opportunity.

For example, when you generate a "una tantum" activity for the date 10/10/2010, this will generate only an engagement on the diary for the day 10/10/2010. Instead, if you generate a periodic "monthly" activity for the date 10/10/2010 till date 09/10/2011, this means 12 engagements will be generated in diary for the days 10/10/2010, 11/10/2010, 12/10/2010 . . . 08/10/2011, 09/10/2011. Moreover, if you send an email to a group of customers, or if you create a new opportunity, the corresponding events in diary will be created.

Once inserted in the diary, the engagements become autonomous from one another. This means that each single engagement could be modified both in its contents (status, title and description) and in its temporal position, that is day and hour. However, all remain linked to the activity record from which they are generated. Should this be modified, then all the engagements in diary that were not directly modified by the user and that are later than the time at which the activity record was modified will be destroyed and re-created under the new planning. On the other hand, all the other records, that is all the engagements explicitly modified by the user, past or future and the past engagements that were not modified, will be maintained in the diary.

The engagements may also be deleted individually by passing a finger over them from right to left or vice versa and pressing the red button to confirm.

Same thing can be done partly for the events. In fact, once generated, also the events become modifiable autonomously in the diary: their title or description can be changed. However, you cannot alter their position in time (unless directly change the cause that created them).

All the engagements are provided with the status "done/not done" which is initially set to "not done". You can modify this status either from within the detail view of the engagement by turning the proper switch, or from the daily and weekly views (and also from the “customer history”), by setting the check mark on the right of each engagement.

The status "done/not done" has no meaning for myCRM. It is just an aid given to the user to mark up the engagements according to its own personal logic.

For the events, in general, you cannot alter their status done/not done. For some of them, in fact, this status is totally hidden, because it does not make sense, while for others it is visible, but always set to "done" status, because the other one would not make sense.

You can define a "follow-up" on the engagements coming from activities (of any type) or from appointments, that is, you can create a new engagement that has the same characteristics as the first, but reported on a later date.

Synching with the device calendar

You can activate synchronization with the device calendar from myCRM “Settings”. You have to choose the calendar among those provided by the application, that is, all the “modifiable” calendars defined in the device.

Once a calendar is chosen, from that time onwards all new engagements/events inserted in the diary and all existing engagements/events that are changed will be automatically shown on the chosen device calendar, in the form of new “calendar events”.

All existing engagements/events, that are not modified, remain excluded from this process of automatic synchronization. If you want to show them into the device calendar, then press the "Sync now" button in the “Settings”, just below the choice of calendars. Pressing the button starts a process that will show on the device calendar all existing engagements/events in diary.

Synchronization with calendar can be deactivated at any time by turning off the switch in “Settings”. By turning off synchronization, all new engagements/events created or modified in the diary of myCRM will no longer be shown in the device calendar. However, all myCRM engagements/events already present in the device calendar will not be deleted from the calendar itself. If you want to delete them, you will need to press the "Remove now" button in the “Settings”, just below the choice of calendars. Pressing the button will start a process that removes from the device calendar all the items generated by myCRM.

As mentioned above, when the synchronization is on, the engagements/events in diary are shown in the device calendar in the form of new calendar events. These events are therefore "copies" of the engagements/events in the diary of myCRM. This means that such events can be edited independently from myCRM. They are, namely, completely independent from the respective engagements/events in myCRM diary.

However, it is strongly recommended not to modify calendar events that are directly generated by myCRM because they can be destroyed and recreated at any time by myCRM, causing, therefore, the loss of any additional information user have entered.

If you want to change a calendar event that was generated by myCRM, therefore, the most appropriate thing to do is to change the corresponding engagement/event on the diary from within myCRM.

Alerts management

The activation of sync with the calendar of the device allows the use of alerts in association with myCRM.

The alerts are the standard system made ​​available by the device calendar to alert the user of an approaching event. The alert consists of a pop-up dialog that appears at the proper moment, together with a "beep" sound.

Alerts can be configured either in the calendar event associated to the myCRM engagement/event or directly in the engagement itself. Again the rule is that the engagement/event in myCRM diary is the "master" and the matching event on the calendar is the "slave". Thus, the recommendation is to configure always alerts from within myCRM by modifying the engagements/events in diary.

MyCRM also offers more flexibility in configuring alerts. In fact:

• You can configure any number of alerts for each individual engagement/event in diary (and not just two as the Calendar application does);
• You can configure alerts as "relative", that is, how long before the event the pop-up must trigger, but also as "absolute", for example, to establish that the pop-up has to trigger on a specific absolute date and time (feature not available in Calendar app);
• there is a greater variety of "relative" alerts than that provided by the application Calendar.
• Alerts can be defined even when creating a new activity. This means that the configuration of the alerts will be automatically brought to all engagements deriving from that activity. Every single engagement may then still be amended. It is the same for the special dates associated with customers.

Synchronization with Google Calendar

Synchronization with Google Calendar is a special case of synchronization with the device calendar.

First, you have to define a new CalDAV account with the credentials of your Google Calendar. To do this:

• Open the device Settings
• Choose "mail, contacts, calendars"
• Select "Add Account ..."
• choose "other"
• choose "add account CalDAV"
• enter the credentials of your account, the address of Google's server, that is, www.google.com, and a description for the account

Once the account for Google Calendar is created, it will be shown in the list of calendars available in myCRM “Settings”. When selected, you will start the synchronization with Google Calendar.

In practice, whenever you create an engagement/event on the diary, this will automatically be brought in the device calendar and automatically on Google's servers. This means that by connecting to Google Calendar from any PC with a browser, you will see in real time (or near) the events added through myCRM.

In order for this synchronization to happen, you need to have an up and running Internet connection. If this does not happen, new events (or changes to existing ones) would be recorded only locally in the device calendar.

To regain alignment with Google Calendar, you will need to re-open the Calendar application when the Internet connection is back up and running and to wait a bit of time. The application automatically and silently will propagate to Google Calendar all local changes not yet synchronized.

“Generic” activities and memos

From the list menu of the diary you can also create new activities. These will have a “generic” type, that is, they will be linked to no entity.

Apart from this difference, the "generic" activities behave in a manner identical to other types of activities.

From the list menu of the diary, you can also create "memos". These are descriptive elements linked to no entity that enable users to store their notes on the agenda.

Cleaning up the diary

The diary is an element of the application that by its nature tends to be filled with many records and this means that the database will grow day by day in its size.

At the same time, however, these records can lose relevance after a certain period of time. Therefore, a feature of automatic cleanup of the diary is provided and used to remove engagements older than a certain time, which can vary from 1 month to three years. If you enable this function (from "Settings" view, turning the proper switch on and choosing the period), at each opening (with a minimum interval of 24 hours) the application will remove the oldest engagements.

GEOCODING CUSTOMERS AND

AREA MANAGEMENT

MyCRM is provided with a powerful geocoding engine that allows an easy display of customers on geographic maps.

The “geocoding” is the process that evaluates the geographical coordinates (latitude and longitude) of a particular civic address or place. The process requires the interaction with the Google geocoding server and therefore it can be done only if you have an active and working internet connection (also a required condition for displaying the maps).

Each time the user enters an address in a customer record, this address is stored as it is, without any control of correctness and existence being made on it.

However, when the user displays the customer list on the map, the geocoding process starts working on all the addresses of those customers. The process takes the costumers’ addresses one by one to be shown on the map and send them to Google which on its turn responds by sending to myCRM the geographical coordinates of the same. These coordinates are then stored in the application to avoid duplicate queries to Google.

In order for the geocoding to be successful, it is necessary that the address field contains in its "value" part the entire address of the customer, including street, house number, post code, town, state. Any part of an address written in the "type" part of the address field, will be ignored.

By opening the address list from the customer detail, you can determine if those addresses were geocoded or not by pressing the little info button placed next to each of them.

The geocoding can fail if the address is wrong or ambiguous. It can also fail if you reach the maximum daily number of geocoding requests allowed by Google.

If an already geocoded address is subsequently modified, its geocoding is lost and it needs to be recalculated again.

In case of a big amount of customers or in case you do not have an internet connection always on and/or with sufficient speed, you can perform the geocoding of all addresses of all customers stored in the database in one shot through the section “Geocoding customers” contained in the “Utilities” menu.

Through this function, you try to geocode all addresses in the database that have not yet been geocoded. Sometimes, in case of high numbers, it can happen that, while carrying out various geocodings, you reach the maximum number of daily geocodings allowed by Google. In this case, you must wait for 24 hours and repeat the operation to complete the remaining geocodings.

Displaying customers on maps

After having applied or not a display filter, from the customer list you can show on the map all customers contained in the list itself. To do this, from the contextual menu of the list, choose the action "Show on the Map". This action will trigger the geocoding for all and just the addresses belonging to the customer list that have not yet been geocoded. Once the geocoding is finished, all the geocoded addresses will be represented on the map with placeholder. All customers who have one or more addresses not positioned on the map (because they are wrong, ambiguous or not geocoded for any reason) will be reported in the list of customers with errors. You can enter this list by pressing the proper button above the map. From that list, the user can access the details of each customer and make the correction of incorrect addresses. After returning on the map, all modified addresses will be automatically geocoded again and, in case of success, they will be placed on the map together with the others.

Viewing a single customer on a map and manual correction of its position

From the detail view of a single customer you can show his addresses on the map. To do this, from the contextual menu of the customer, choose the action "Show on the Map". This will open the map, will make the geocoding of the addresses of the customer and will put on the map the placeholders of the geocoded addresses.

In some cases, although there was a proper geocoding, it is possible that the position where the placeholder is placed is not the right one (for example, when the road referred to by the address is very long and the placeholder is placed at a considerable distance from the actual position of the address).

In cases like this you can edit the map, by pressing the button "edit" and then manually move the placeholder to the desired position. To move the placeholder, you have to press for a few seconds on the same until it is "up". At this point, by dragging your finger across the screen, you can move the placeholder. Then, by raising the finger, you drop the placeholder to the new location, which is then associated with the address. Finally, by pressing the button "save", you will record permanently the changes in the database.

In this way you can also manually place the placeholders for those addresses whose geocoding fails for any reason. In this case you need to adopt the following method:

1.   you must make sure to place a new placeholder in an approximate location on the map. To do this you can take one of three following strategies:

a.    you find an adjacent street that is recognized by Google and use this (and then you add in the customer notes the exact address);

b.    you transform the address by putting in parentheses the part that is not recognized and leaving outside only the city. Eg. address, "Via Borroncino di Sotto 65 Montevarchi AR Italy" is transformed into "Montevarchi AR Italy (Via Borroncino di Sotto 65)". In this way, Google ignores the part in parentheses and sets the marker to the center of the city. When you press on the placeholder, however, the full address, including the part in brackets, appears, thus providing the detailed indication;

c.    you combine the two previous techniques; therefore, always with reference to the unknown address of Montevarchi, you could enter the following address: "Via Giuseppe Verdi Montevarchi AR Italy (Via Borroncino di Sotto 65)";

2.   Once the approximate address has been positioned on the map, you can manually move its placemark to the position you consider correct.

Associating addresses to areas

The customer addresses can also be associated to areas. The association takes place in the address list when you are in editing mode, by pressing the little button on the right of the field “area” placed below the address and by choosing the area from the list of the proposed ones.

The areas are defined by the user by giving them a simple unique name.

The area, which at the time of its creation is a simple label, becomes let’s say "alive" when it begins to be associated with already geocoded addresses of the customers. Indeed, the application keeps for each area information on what the minimum and maximum latitude are and the minimum and maximum longitude of all addresses that have been associated to it.

Therefore, each area takes the form of a virtual rectangle that covers the territory of all addresses associated to it.

From this concept of a “territorial rectangle” two very important concepts derive: “direct association” and “indirect association”.

• “direct” association: given an address, it is associated “directly” to the area X if the user has done the association to the area X through the direct choice of the area by using the interface during the insertion/editing of the address.
• “indirect” association: on the contrary, the address is indirectly associated to the area X if its geographical coordinates fall into the territorial rectangle defined by the area X.

Consequently, the “direct” associations are those made by the user, while the “indirect” associations are those automatically calculated by the application with no intervention of the user.

The “indirect” associations allow discovering customers that fall into an area X even if they have been associated to no area or they have been associated to different areas that are fully or partially overlapping with the area X.

Whenever the user makes a "direct" association of an address to an area X or he deletes the previous "direct" association (by linking the address to another area or by associating it with no area, or even by eliminating or modifying the address or the entire customer), the territorial rectangle defined by the area could have a variation. In this case, the area needs to be "recalculated".

The recalculation of an area is an operation that could be costly in terms of time taken and therefore it can only be made statically, through the special section "Area Management" accessible from the "Utilities" menu. In this section all the areas are listed and for each of them there is an indication of whether it needs to be recalculated.

The recalculation of the areas and the geocoding of customers are the two sides of the same coin. One needs the other. So in case of intensive use of areas, it is normal that geocoding and recalculation of the areas must be carried out several times alternately, when new customers are added or old customers are changed or deleted.

On the other hand, in normal cases, the customer data base tends to stabilize over time, and therefore, after a certain number of cycles, there is no more need for geocoding and recalculation of the areas.

As a practical suggestion, we recommended to make, in order, a general customer geocoding and a general recalculation of the areas after a massive import of customers.

RELATIONSHIP MANAGEMENT

With the concept of "relationship" we mean an interaction between the user of myCRM and one or more of its customers. We define the following types of relationships:

• Email
• Phone call
• Fax
• Sms
• Mail
• Meeting
• Intermediary

We define also a “direction” of the relationship which may be of two types:

• Inbound
• Outbound

A relationship may be, for example, an email sent to a customer, or a phone call received from a customer; it may be a meeting made ​​at a customer site (ie, a visit to the customer) or made at your office (ie, a visit of the customer); it may be also an intermediation initiated by the customer or a fax sent to him and so on.

A relationship may involve a single customer or a group (even a very big one) of customers. Consider, for example, an email that can be sent simultaneously to a list of customers, or a seminar for a product presentation which involves some customers.

MyCRM allows recording of relationships and links with customers involved in them and allows view them in the diary and in the history of the customer.

According to what has been explained above, the relationship is a concept that concerns the past (opposite to activities). It represents, namely, something that at the time of registration has already happened.

In the recording you will insert a description of what has happened, what has been said or written with the customer, what communications have been made, and so on.

Creating a new relationship

As mentioned above, the relationship may involve one or more customers. Depending on the case, you will use a different path to create the relationship. In particular, to create a relationship with one customer, you must enter in the customer detail view and, from its contextual menu, select "Create new relationship ... ".

However, if the relationship involves a group of customers, you need to locate this group in the customer list and select the item "create new relationship...." in the list menu.

The identification of the customer group can be done in several ways: it can be done by applying one or more display filters, or by entering in selection mode and manually selecting customers to include in the relationship.

Once the customers are chosen, you will proceed to add a short title to the relationship and a detailed content/description. Finally, you will choose the date and time when the relationship happened and, of course, the type of relationship and its direction.

Using of relationship templates

To facilitate the insertion of long and repetitive descriptions, you can create one or more templates that can be retrieved during the creation of the relationship. The choice of a template has the effect to automatically fill the title and the description of the relationship with the values ​​associated with it.

To generate a new template, you must press the button "Save as Template" during the entering of the relationship. The new template will be saved with a name equal to the subject field and will be associated with the type of relationship currently set. This means that, when you retrieve the available templates, you will see only those associated with the type of relationship that is being recorded.

The template will store inside it the values, ​​present at the time of its creation, of the fields "subject" and "content/description". These values ​​are then reapplied to these fields when the template is choosen from the list.

The total set of the available templates can be viewed by opening the section "Relationship templates" found under the item "Other Entities" in the main menu.

To delete a template, identify it in the general list or in the list generated during its insertion and filtered by the relationship type, then swipe the finger from left to right (or vice versa) on the item, and finally press the red button to confirm.

Generating event in diary

Once the relationship has been created, an event in the diary that summarizes the type and direction of the relationship and lists all the involved customers is automatically generated. Starting from this event you can retrieve the details of the relationship itself and the detail of the involved customers.

The generation of the event in diary allows the relationship to appear in the customer history of each customer involved in the relationship itself.

Therefore, starting from the diary, you can retrieve the list of all customers involved in a relationship, while starting from the history of a single customer, you can retrieve the sequence of all the relationships maintained with that customer.

Customer relationships list

From the detail view of a customer, you can view the list of relationships by opening the contextual menu. This list reports all the relationships mantained with the customer, whether they are individual relationships, or relationships that have simultaneously affected other customers.

From the main menu of the application, instead, by selecting "Other Entities" => “Relationships”, you can access the general list of relationships. This list shows, therefore, the entire set of relationships stored in myCRM for all customers.

Deleting a relationship

A relationship can be removed by swiping the finger from left to right (or vice versa) and pressing the red confirmation button on the item that represents the relationship itself. This can be done either from within the list of relationships of a specific customer, or from the general list of relationships. Furthermore, the operation may involve either a relationship with a single customer, or a relationship related to many customers.

When you are in the list of the relationships of a single customer and you want to delete a relationship that involves more customers, you will be asked whether you want to delete this relationship only for that customer or for all. Deleting a relationship for all customers means that the relationship is completely removed from the database of myCRM and the underlying event is also removed from the diary and from the history of all customers involved.

On the other hand, deleting a relationship only for the current customer means that the customer will be removed from the list of customers involved in the relationship. The relationship, however, will continue to live for other customers and the event in the diary will only be updated accordingly.

Nevertheless, when you are in the general list of the relationships or when you are in the list of relationships of a single customer and the relationship you are removing involves only that customer, the elimination of the relationship corresponds to the actual removal of the relationship from the database of myCRM and to the cancellation of the corresponding event from the diary.

Relationships with “company” customers

When you create a new relationship starting from the contextual menu of the detail view of the customer, the relationship created will involve both the company customer for which you are working, and all its simple contacts that belong to it.

On the contrary, if the customer of type company appears within a group of customers for which you are creating a relationship, then the relationship will involve only that company customer (as well as the other customers of the group), but not involve its simple contacts that belong to it.

Eventually, when you view the list of relationships of a company customer, this list will contain both the relationships that directly affect it, and the relationships involving its simple contacts.

SENDING EMAILS TO CUSTOMERS

Sending an email to one or more customers is a particular case of relationship, ie a relationship of type "email" with an "outbound" direction.

This relationship is interesting because you can send emails directly from inside myCRM. This means that, in general, you will identify one or more customers as addressees, ie you will identify the set of recipients; you will create the email message, including, when needed, one or more attachments and then you will send the message. After this, myCRM will record automatically the corresponding relationship, with "outbound email" type, placing as the object of the relationship, the subject of the email and as content/description, the body of the email.

Creating and sending the email

To send an email to a customer, you must first access his detail view and from there, by opening up its contextual menu, select "Send email to the customer...". Otherwise, if you want to send an email to a group of customers, you must first view the group of customers in the customer list and select there "send email..." by opening up the contextual menu of the list.

As usual, the group of customers may be determined by applying one or more search filters or by a manual selection. Also, if you send the email from the detail view of a "company" customer, the list of recipients will be formed by the same "company" customer together with all his simple contacts.

From the menu items "send email..." and "send email to the customer..." you access the form for entering the email in which, besides being able to enter the subject and body of the email, you may choose other things that are:

• The location of the addresses: that is, you can choose in which of the fields "To:", "Cc: "and "Bcc:" of the email, you want to put the list of email addresses associated to the recipients.
• The addresses to use: considering the general case of a customer with more than one email address, you can determine whether to include in the list of addresses only its main address, or include all of its addresses. In this context, the so-called "main" address is the one that appears in detail view of the customer in first position, while all other addresses are those that can only be seen by opening the list of email addresses, by pressing the small button to the right of email field, or displaying the customer in “plain” mode.
• The attachments: that is, the user can choose to attach one or more documents to the email, among those on the list of the available documents. This list is formed by taking all the existing documents in the public folder of the application. The contents of this folder are handled through the standard mechanism of the iTunes document sharing. You can also attach any number of photos taking them from the photo library of the device. Altogether, the documents that you can attach can be of any type and any number. However, the operating system limits the maximum overall size of attachments to 5 MB for the iPhone and to 15 MB for the iPad. Note, finally, that the attachments are not stored in the relationships, but only their names at the bottom of the message text.

Once the email and all its options have been set, you can press the button "Pass to Mail". This fact causes the creation of the actual email message (directly managed by the "Mail" application of the device) with the complete list of recipient email addresses put in the chosen destination field, with subject and body already filled and with possible attachments already loaded.

At this point, everything is ready for the effective email sending. The user will press the "send" button to send the email, or "cancel" button to abort the operation.

If you press the "send" button, a new relationship will be automatically generated with type "outbound email" as described above. The date and time of the relationship will be those in which the button was pressed. The list of customers involved in the relationship will coincide with the list of customers that have at least an email address included in the list of recipient addresses. In other words, if a customer is included in the group of recipients, but it does not have any email address, the customer will not be affected by the relationship created as a result of the sending of the email.

“Diligent” behaviors

The mechanism described above can be defined semi-automatic, in the sense that there are some points where the user of myCRM is required to adopt "diligent" behaviors. If these behaviors are not applied, the application will not be able to realize it and consequently record false or inconsistent information.

The “diligent” behaviors to be followed are:

1.   Do not change subject, body and attachments of the email generated by the pressing of the button "Pass to Mail". This operation, in fact, makes a mere transfer of data from myCRM to the Mail application. MyCRM assumes that these data are not modified and these will be stored in the relationship. If you change them from within the Mail message, these changes will be sent to customers, but they will be lost by myCRM. Therefore, an inconsistency between the texts stored into the relationship and the texts actually sent to customers will be generated.

2.   The destination fields of the Mail message can be modified by adding or removing email addresses, but with sagacity. You can add additional addresses, but addresses belonging to customers who are not part of the group of recipient customers, but which are registered in the database myCRM, should be excluded. This is because otherwise the added customers would not be linked to the relationship below. Some addresses may also be eliminated, but only if other addresses of the same customer have been included. This will safeguard the link between the underlying relationship and the customer. The total elimination of the addresses of a customer would have the effect of sending nothing to him, even though myCRM would store the fact that the user has received an email. This would be an inconsistency. You can, however, easily add other email addresses that do not belong to any customer stored in myCRM or that belong to customers already present in the group of recipients.

3.   Make sure the message is actually sent. Pressing the "send" button puts the message in the Mail's "outbox" and tells myCRM that the message has been sent. MyCRM records this fact as definite, but actually it is not so. In fact, the message may get stuck in the outbox queue due to communication problems or incorrect addresses or other reasons. In this case, you should check whether Mail has the possibility to pick it up from the queue and retransmit it, or if the message sending was definitely aborted. In this latter case, the user must manually identify the relationship that myCRM has already created automatically after the sending of the message and delete it for all customers. Keeping it in memory, in fact, would represent an inconsistency with the reality of facts, since the message, while it never departed from Mail, would be considered sent to customers by myCRM;

4.   Make sure the message does not "bounce back". Sometimes, if an address is incorrect, the message is sent back to the sender by the server of the concerned email domain. Again, the user must identify the customers affected by the bounce and understand if they have still received the message through another of their addresses or have not received it at all. In this latter case, these customers should be manually excluded from the relationship created by myCRM. To do this, you need to go into the detail view of each of these customers, open their list of relationships, and delete, for each of them, the relationship in question, making sure to delete it only for the current customer and not for all.

Very large recipients number

The functionality of sending email to customers of myCRM is very powerful, but, as we have seen, is also very delicate and must be used with caution. In fact, you can easily make mistakes that force you, then, to manually intervene into the application in order to repair them.

The higher the number of recipients of the email the more evident it becomes. But the ability to send an email in one shot to a large number of customers, maybe even to the total number of customers in the database, and keep track of the relationship in an orderly manner in the database and in the diary, and with the added possibility to provide attachments (which is not allowed if you use the Mail application), is the real power of this feature.

A limit that is imposed by the operating system is the maximum number of email addresses within the same message. Currently this limit is 99 addresses. To overcome this limitation, it is necessary to adopt a technique that involves taking the set of recipients of the email addresses and split it in many groups of less than 99 elements each. For each of these groups, you will then create an email that will be sent by the user. Also, the relationship below will be divided by groups of customers.

We explain the whole with the following example.

Imagine you are sending an email entitled "offer" to a group of 1000 customers. After composing the email, chosen the attachments, and chosen all other options, you press the button "Pass to Mail". At this point, myCRM realizes that the limit of the 99 email addresses is exceeded and divides the set of addresses in smaller groups than 99 items each. Imagine that the resulting number of groups is 11. At this point, the first email with subject "proposal - (1/11)" will be proposed. The user sends this email by pressing the "send" button and myCRM will do two things: 1) it will record a new relationship with type "outbound email" and with name "proposal - (1/11)" and 2) it will propose a second email, identical to the first, except that its subject will be "proposal - (2/11)". The user will have to send also this second email by pressing the "send" button. All this will continue until the eleventh email when the cycle ends.

To sum up, when the number of recipients is very high, it may happen that instead of sending a single email, you could send a certain number of them, and, for each email, a new relationship, that links only the customers affected in that email, is created in myCRM. Both the emails and the relationships will be characterized by having the same name, unless the index sequence.

Again, the user is required to have a "diligent" behavior, in the sense that he will have to send as many emails as the groups of addresses in which the original list of recipients was split and has to verify that each of these emails was actually sent.

If the user decides to cancel the sending of one of these emails, myCRM will not record the corresponding relationship and will proceed to propose the next email.

Sending email to a single address

From the detail view of the customer you can view its email addresses. For each of them the "send" button allows to send an email directly to that address. The procedure is identical to what happens in the general case of sending emails to customers, except that the list of recipients will contain only the chosen address. Also in this case, therefore, the user will be required to adopt a "diligent" behavior as described above.

NOTE:

Like the "send" button placed next to each email address of the customer, in the iPhone version of the application there is a "call" button is present next to each phone number. Pressing this button, however, you do not create any relationship below. So if, as a result of pressing the "call", you established a telephone conversation with the customer, you will then have to manually create a new relationship of type "outbound phone call" and insert inside it the content of the conversation.

DATABASE BACKUP AND RESTORE

The database used by myCRM is stored entirely within the device. It is therefore essential to preserve the possibility of recovering it in case of loss or breakage of the device itself or even in case of incorrect operations performed by the user on the data.

The database is stored in files that are, from the operating system point of view, normal application data files. These ones already enjoy all the opportunities offered by Apple for backing up and restoring data for any application.

However, MyCRM has also an autonomous backup and restore system that allows maximum freedom and flexibility. With this system you can backup the database when you want, as many times as you want and you can store the backup file where you want. So, the user can take several "snapshots" of its data at different times and may at any time thereafter restore any of them.

The backup operation consists in the generation of a particular file that the user then will have to store somewhere in a safe place. The restore operation, instead, consists in retrieving a backup file from the safe location and giving it to the application which, by reading it, will be able to rebuild the database with the data registered at the time of the backup operation. Thus the restore operation for its very nature, permanently and irreversibly erase all data on the database present at the start of the operation and replaces them with those coming from the backup file.

From menu "Utilities" => "Database backup" you can access the section where the user can perform the backup, while from the menu "Utilities" => "Database restore" you can access the section where the user can perform database recovery.

Both sections have a bar at the top where the user chooses the destination/source of the backup file.

For both we have two possibilities, "iTunes" and "Google Docs", while a third option, "Reset", is only for restore. We will explain each of them in detail.

iTunes

By selecting "iTunes" as a backup destination, you make myCRM deposit the file generated by the backup operation in the public folder of the application. By accessing this latter, the user has the ability to retrieve the backup file and transfer it on its pc/mac and from there to store it in any appropriate place.

The backup files are generated with the following scheme for their name:

mycrm.db.<year>-<month>-<day>_h<hour>.<minutes>.bkp

where <year>-<month>-<day> h<hour>.<minutes> is the timestamp of the moment in which the backup file was generated. Eg.:

mycrm.db.2011-09-01_h15.30.bkp

To carry out the restore, you must do the reverse process, ie, you retrieve from your pc/mac the backup file to restore and you load it into the public folder of the application. Then you open the section of the restore in MyCRM (menu "Utilities" => "Database restore") and choose "iTunes" in the top bar. Eventually, by pressing the blue small button on the right of the label "choose the backup file", you will open a list of all the backup files present in the public folder. From this list you will choose the appropriate file and then launch the restore process by pressing the button "make the DB restore".

In the box below, called "console", the application will report the outcome of all stages of the recovery. If an error occurs, the original database will be restored.

Please notice that the list of backup files in the public folder of myCRM is obtained by applying the filter "*.bkp". This means that the user can rename backup files in total freedom and reload them in the public folder with their new name. The only constraint is that these files will always have to maintain the final extension ".bkp".

Google Docs

By selecting "Google Docs" as destination of the backup, you make myCRM deposit the file generated by the backup in the documents area of your Google Docs account.

To use this option, you must have an active Google Docs account with sufficient space.

The account (username and password) must be initially inserted through the "Google Docs account" section accessible from the "Utilities" => “Settings” menu.

Please notice that, by choosing "Google Docs", you choose a remote location accessible only via Internet. Therefore it is necessary that during this phase the Internet connection of your device is up and running.

To perform the backup operation, press the button "make the DB backup". Depending on the type of database, the backup can be composed of several phases and can take some time. It is therefore provided a guide to what the application is doing time after time in the field labeled "Console".

The first step is to create a database file encoded according to an exchange format (not readable). Then, depending on the size of this swap file, this latter is divided into one or more segments which then are sent one by one in Google Docs.

When finished, by entering in Google Docs with a normal browser, you will see the various segments sent. The name format of these segments is as follows:

mycrm.partdbdump_<dbversion>_<year>-<month>-<day>_h<hour>.<minutes>_(<n° segment>|<tot n° segments>)

where:

• <dbversion>: it is the version of the database (generally different from the application version)
• <year>-<month>-<day>: it is the date when the backup was made
• <hour>.<minutes>: it is the time when the backup was made
• <n° segment>|<tot n° segments>: it is the number of the segment as regards to the total number of segments that make up the backup.

Example:

mycrm.partdbdump_3.0_2011-01-04_h22.04_(2|4)

The name of these files should not be in any way changed by the user from within Google Docs, otherwise it will be impossible to perform recovery in case of need.

The various segments sent to Google Docs appear as files containing a sequence of characters without spaces and with no apparent meaning. These files are not meant to be read or modified by the user. They contain a code that can be interpreted only by myCRM during the restore phase. Their presence on Google Docs is therefore to be understood as mere storage on an external device.

If necessary, you can restore the backup previously made and sent to Google Docs.

To restore the database, go to the "Database restore" section accessible from the "Utilities" menu and choose “Google Docs” in the top bar.

First, the user must choose the backup file to restore. To do this you have to press the little button on the right of the "choose the backup file" label. Pressing the button will trigger the connection of myCRM to Google Docs and the retrieval of the list of all available backups, sorted by date and time decreasing.

The list will be filled only with backups having version equal to the current database one. If you want, you can expand that list to all previous versions by turning the switch.

After having chosen the backup file to restore, you kick off the restore operation by pressing on the proper start button.

The restore operation completely and irreversibly deletes all data currently present in the database and replaces them with those coming from the backup file.

In the console field, you can follow the evolution of the operation and see its final outcome.

In general, the various segments that make up the backup file will be downloaded one by one and they will be then put back together in a single swap file. This is consequently decoded to generate the new database that will be later replaced to the old one.

In case something goes wrong in this whole series of operations, the old database is restored without loss of data.

Reset

From the section of the database restore is also possible to choose a third option in the top bar: “Reset”. This option allows making a full reset of the database. By launching this operation, you make the database be restored to its original state, as it was when you installed the application.

Of course, this means the permanent loss of all data in the database.

Reset operation also deletes all preferences and settings of the application.

The database reset requires neither the presence of files in the application public folder nor a Google Docs account or an active internet connection.

Transfering the database on another device

The mechanism of the backup/restore of the database adopted by myCRM allows also the transfer of the database on another device, be it iPhone or iPad. Therefore, it is possible, for example, to backup the database from myCRM on an iPhone and then importing it on myCRM for iPad. It is important that the version of myCRM with which you are restoring the database will be greater than or equal to that with which you have backed up the database.

When the device on which you are restoring the db, namely the "target", is different from the device in which the db was backed up, namely the "source", the license level will not be transferred. This means that in the target device you have to restore separately license level. There are two possibilities:

1)   The type of device remains the same, ie both source and target devices are iPhone or iPad. In this case, in the target device you can proceed to restore the license without any additional cost (see below, chapter "license management")

2)   The type of device is different, ie the source device is an iPhone and the target device is an iPad or vice versa. In this case, on the target device you must purchase a new license level (which can also be different from that present in the source device).

In both cases, as long as the license is restored, all data are still available for reading, editing and deleting, but you cannot add new records beyond the tenth (basic license GRATIS10REC).

DATA EXPORT

Data export consists in creating files containing lists of records belonging to the entity to be exported. Records can be written either in a readable format or in CSV (Comma Separated Values), which is a very common exchange format that allows the import of data into other softwares such as Microsoft Excel.

Entities that can be exported are:

• Customers
• Opportunities
• Sales
• Activities
• Engagements and events (in diary and in the customer history)
• Areas
• Addresses with area (that is, all the “direct” associations of addresses with areas)
• principals

In addition to the format, the user can also choose the encoding with which the file will be generated. You have the following choices:

• Unicode (UTF8): it is the universal encoding, readable, in general, by all modern programs, both on PC and Mac;
• Macintosh (MacRoman): it is the encoding used in the classic Mac environment. It allows you to properly read the files with any program on Mac;
• PC (ISO Latin 1): it is the encoding used in the classic PC environment. It allows you to properly read the files with any program on PC;

The data export can be accessed either through the menu "Utilities" or from the contextual menu of the above mentioned entities (only for the main ones).

The generated file will be stored in the public folder of myCRM and can either be retrieved through the iTunes document sharing or attached to an email and sent via internet.

From within the detail view of each of these entities through the contextual menu the single record can be sent via email. In this case, the exported data record will be directly written, in readable format, within the body of the email.

All export files are maintained over time into the public folder of myCRM and can only be deleted by pressing the "delete old files" button (or manually deleted through iTunes).

IMPORT CUSTOMERS

You can import customers into myCRM either from a Google Docs spreadsheet or from your contacts stored in the device through the Contacts application.

In both cases, you have the possibility to choose whether to perform the checking for duplicates. This check consists in determining if that name already exists in the customers list at the moment of its importation. If it exists, you have the further possibility to choose to completely ignore that name, leaving the original name untouched, or performing a merge of its data with those of the original one.

Please pay attention that both the check for duplicates and the merging of the data are operations that lead to a slowdown of the entire process of importation. Therefore, you should disable those functionalities every time you are sure there are no duplicates in the contacts you are going to import with those already present into the customer list.

Eventually, keep in mind that the import of the customers is an operation that could deeply alter your database and it is not undoable. Therefore IT IS STRONGLY RECOMMENDED TO DO A DATABASE BACKUP BEFORE PROCEEDING WITH THE IMPORT OF CUSTOMERS.

Import from Google Docs

When you import customers from a Google Docs, the spreadsheet must have the following format:

• the row 1 must contain the names of the columns, that are: "name", "codes", “company”, "addresses", "phones", "faxes", "emails", “tags”, "notes";
• the column "name" must be always present, the others are optional;
• the order of the columns is free; between them you can place empty columns and/or columns of other type that will not be imported;
• starting from row 2, the data are input;
• the data rows must be contiguous. The first empty encountered row will end the importation process;
• the data of the column "name" are mandatory, the data of the other columns are optional;
• the columns "codes", "phones", "faxes", "emails" can contain data either in the single form or in the form of "type/value" sequence;
  • a "type/value" sequence is formed as: <type-1>;<value-1>|<type-2>;<value-2>|...|<type-n>;<value-n>;
  • for example, if you want to insert more than one phone number, you can write a similar expression to the following: "mobile;328123456|office;0698765|home;0256789"

A more in depth question should be made for the "addresses" column. You can insert here a sequence of one or more items separated by the "|" (pipe) character.

Each of these elements may consist of one, two or three sub-elements separated by the ";" (semicolon) character. The different cases that may occur are the following:

• a single sub-element: in this case, it represents the address:
  • eg: " 5th Avenue, New York”
• two sub-elements: in this case, in general, the first represents the type and the second the address…
  • eg: “Office; 5th Avenue, New York”
• … but, if the second item contains the prefix “area:”, then the first sub-element represents the address, while the second sub-element (without the prefix) represents the area associated to the address.
  • eg: “5th Avenue, New York; area: Manhattan”
• Three sub-elements: in this case, the first represents the type, the second the address, while the third is the area. In this case, there is no possibility of confusion, so you can omit the prefix.
  • eg: “Office; 5th Avenue, New York; area: Manhattan”
  • but also: “Office; 5th Avenue, New York; Manhattan”

Eventually, there is the column "tags", which will contain the list of tags to associate with the customer. Tags can be separated by any of these separator characters: semicolon (";"), comma (","), pipe ("|"). The space (" ") is not considered as a separator character. As a consequence, the tags can be formed by multiple words separated precisely from space.

In the determination of the tags, there shall be no difference between uppercase and lowercase letters. So, for example, the tag "myCRM" will be treated identically to the tag "mycrm".

If there are customers who have non-zero values in the "company" column, then the spreadsheet must contain the rows that represent these values. Eg. if the customer Steve Jobs has the value "APPLE inc" in the company column, then the spreadsheet must also include a line for the customer "APPLE inc".

The customers’ location within the spreadsheet representing companies can be anything, but the following rules must be followed:

• if the company customer preceeds one or more customers associated with it, the company customer must include its name in the "company" column.
• if the company customer comes after all the customers associated with it, he must have an empty value in the "company" column.

to see an example of spreadsheet, click here:

Import from Contacts

When you import customers from your personal contacts list, you have the possibility either to import the entire list of contacts or to choose only a subset of them. Moreover, you can also choose what format the device contacts have to be imported with. We will explain how.

The first choice button in the view allows choosing what to import. At the beginning, the choice is set to “import all contacts”. However, you can modify it by pressing the little blue button on the right. By pressing the button, the entire list of your device contacts will be loaded. Initially, all items are selected. Then, you can change the selection as you want by tapping on each item or using the upper right button. Through this latter you can select (“select all”) or un-select (“select none”) in one shot all items of the list.

Once you have decided “what” to import, you have to decide “how” to import by pressing the second choice button, named “format”. The following options are available:

1.   Last name, name [+company]

2.   Name, last name [+company]

3.   Company – last name first name

4.   Company – first name last name

5.   Last name first name – company

6.   First name last name – company

The first two options allow you to create a “simple contact” customer for the device contact and, possibly, a “company” customer if the device contact has a non empty company field. For example, suppose you have two contacts in your device. The first is:

• First name: Steve
• Last name: Jobs
• Company: Apple

And the second is:

• First name: Bill
• Last name: Gates
• Company:

When importing with the first format option, you will create in myCRM three customers: the first will be a “company” customer with name “Apple”; the second will be a “simple contact” customer with name “Jobs Steve” and with a “belonging company” link to “Apple”; the third will be a “simple contact” customer with name “Gates Bill” and with no “belonging company” link.

Therefore, options 1 and 2 act in the same way. However, the first saves customers name as “last-name first-name” whereas the second saves name as “first-name last-name”.

On the contrary, all the other four options do not create any “company” customer, but register the company name into the name of myCRM customer. For example, importing the two sample contacts with the option 4, you will create in myCRM only two customers, both with “simple contact” typology, both with no “belonging company” link set and with the following names:

• “Apple – Steve Jobs”
• “Bill Gates”

LICENSE MANAGEMENT AND PRICE LIST

The application myCRM (for iPhone and iPad) can be downloaded for free from the App Store.

It is set to the license base level, FREE10REC, which allows full use of all functionalities up to a maximum of 10 records for each of the main managed entities that are: Customers, Opportunities, Sales, Activities, Relationships, Principals, Areas, Special Dates and Tags.

This means, for example, that no more than 10 customers, more than 10 opportunities, etc. can be entered.

Except for this limit, the application is fully usable in all its functions, which are the same in each license level.

Therefore, with FREE10REC license level you may test freely and indefinitely the application to see if it suits your needs.

For a definitive use of the application, further license levels are available, as reported in the following table:

All license levels can be purchased directly the application using the In-App-Purchase mechanism by opening the "License Manager" section.

"License Management" section

In this section you can view the current license level installed on the app and you can also access the App Store to retrieve the list of available levels. To do this, press the small button on the right of the field "license to purchase". After a few seconds, you will see the list of available levels. By selecting one, you will report it in the field "license to purchase" and the button "Buy" will appear.

By pressing the button "Buy", you will start the product purchasing procedure. It requires the Apple account that you normally use for all other App Store purchases.

After answering the various warning and confirmation messages sent by Apple, the actual purchase transaction will start. Please notice that it might take several seconds or minutes.

In this period of time the user can continue using the application normally and may even close it. In this case, the procedure will be completed when the application will be re-opened.

When everything is successful, the user will see the "Current license" field updated with the newly bought level and the application will automatically be set to use that level.

In the section "License Management" also the button "Restore license" is present at the bottom. This button is used in all cases where, for any reason, the application has lost memory of what its license level was. This can happen, for example, when the application is removed from the device and then restored on it. In those cases, by pressing the button "Restore license", you are allowed to recover from the App Store the last purchased license level with no additional cost.

If also the license restoring were unsuccessful, please remember that you can still proceed to purchase the license again, considering the fact that if you use the same account, the App Store will not charge any further amount, but it will make a new completely free transaction.

Transfering license to a new device

When you transfer the database, through backup/restore, on a different device, but of the same type (eg. from an iPhone to another one or from an iPad to another one) you can restore the license level.

In this case we must keep in mind the Apple rule that allows you to share for free any product purchased from the iTunes / App Store on up to 5 different devices. Beyond this limit you must proceed to a new purchase.

Therefore, in order to restore the license after transferring the database to a different device (but with the same type) it is sufficient to act as if you would buy back again this license on the new device. After entering your iTunes account (which must, however, necessarily be the same as that used in the first purchase) and having answered to the messages of confirmation, the system will notify you that the product you are going to buy (ie, the license level) has already been purchased by you previously and therefore it will be downloaded again for free.

If instead the type of devices is different, that is, you are switching from an iPhone to an iPad or vice versa, then you will necessarily purchase the license again. This is because the two versions of myCRM for iPhone and for iPad, although functionally identical, are considered by the App Store as two distinct and separate applications, and this prevents, according to the Apple rules, to transfer purchases to each other.