CRM : données structurées

Dans cet épisode, nous définissons les données structurées et parlons de ce qu'elles signifient par rapport au CRM. Il est important de comprendre le type de données stockées dans votre CRM, afin de savoir ce que vous pouvez accomplir avec CRM.

00:19 Andy Shore : Salut à tous, bienvenue sur Clues for the Clueless CRM Marketer. Aujourd'hui, nous allons entamer une conversation sur les différents types d'informations que vous stockez dans votre CRM. Et nous allons commencer avec des informations structurées. Alors qu'est-ce que ça veut dire ?

00:36 Paul Rijnders : D'accord, de nombreux CRM, en particulier les CRM traditionnels, sont basés sur une sorte de base de données structurée, ce qui signifie qu'il y a une sorte de base de données SQL ou MySql en dessous où il y a des tables, et les tables sont un peu comme une feuille de calcul où les lignes représenteraient les enregistrements et les colonnes représenteraient les informations de champ. Ainsi, par exemple, peut-être que la première colonne pourrait être le prénom… Première colonne. Disons que nous avons un tableau de contacts, la première colonne est le prénom, la deuxième colonne est le nom de famille, la troisième colonne est le deuxième prénom, la quatrième colonne est l'adresse, la cinquième colonne est la ville, etc. Et la plupart des CRM seront livrés avec un ensemble standard de champs par défaut, et ce sont les choses dont ils pensent que vous aurez besoin. Adresse e-mail, numéro de téléphone ou peut-être téléphone portable, ce genre de chose, pour un contact. Peut-être que si c'est pour une opportunité alors… Ce qui serait une table différente pour ainsi dire ou un type d'enregistrement différent pour ainsi dire.

01:34 PR : Vous auriez le nom de l'opportunité, quel en est le montant, à quelle étape en est-elle, quand est-elle due. Dans l'activité, il peut s'agir de quel type d'activité est-ce, quand est-ce censé être dû, à qui est-il et à quoi est-il lié. Est-ce lié à un projet ou une opportunité ou un autre type de disque etcetera ? Mais ceux-ci seront tous très structurés, ce qui signifie qu'avant que quelqu'un entre n'importe quel type d'information, il doit y avoir un espace pour cela. Il doit y avoir une rubrique pour ça. Il n'y a pas de place de forme libre pour cela.

02:04 PR : Alors cela soulève la question, et si j'ai besoin d'un endroit libre pour cela ? Eh bien, puisqu'aujourd'hui nous parlons d'informations structurées, peu importe qu'il y ait d'autres endroits où vous pouvez les mettre dans le CRM, mais pour un CRM basé sur une base de données SQL, ce que vous voudrez probablement, c'est que vous voudrez une sorte d'administrateur pour configurer certains champs personnalisés à l'avance. Ainsi, par exemple, dans les e-mails de référence, lorsque notre équipe de vente et d'assistance par e-mail de référence utilise le CRM, ils ont des champs client qui ont du sens pour nous. Par exemple, quel type de nouveau plan marketing cette personne a-t-elle ? Quel est le statut du compte ? Quelle est la taille de leur liste ? La liste est un peu longue. Votre entreprise est peut-être différente, vous avez peut-être un magasin de beignets et vous voulez lister quel est leur beignet préféré ? Peut-être que vous êtes un atelier automobile et que vous voulez lister le type de voiture qu'ils ont, puis quelle année est-il, est une autre colonne.

02:57 PR : De toute façon, la liste s'allonge encore et encore, mais ce que j'essaie de dire, c'est que vous allez avoir des colonnes structurées pour ainsi dire où vont ces informations. Alors pourquoi est-ce utile de procéder ainsi ? Eh bien, et encore une fois, peu importe la conversation entre une base de données non SQL par rapport à une base de données SQL traditionnelle, SQL étant au moins SQL avec une base de données SQL que les choses doivent rentrer dans leurs jolies petites catégories à l'avance afin que vous puissiez créer des rapports dessus plus tard , ou vous pouvez créer des vues et vous pouvez créer certaines conditions. Parce que plus tard, vous voudrez peut-être dire : « D'accord, j'ai ouvert mon tableau de bord des contacts, mais oh mon Dieu, je regarde 100 000 contacts. Est-ce que j'en ai vraiment autant ? Eh bien, je veux juste voir les contacts que je possède qui vivent dans l'état du Wyoming, dont la voiture est une Toyota et leur beignet préféré est French Cruller.

03:51 PR : Donc vous mettez toutes ces conditions et les conditions peuvent être vraiment une sorte de… Elles doivent toutes être vraies, n'est-ce pas ? Ou vous pourriez avoir des conditions selon lesquelles n'importe laquelle d'entre elles peut être vraie. Vous pourriez donc dire : « D'accord, la voiture doit être Toyota, mais le beignet préféré doit être soit French Cruller ou Chocolate Long John ou un beignet glacé. Donc n'importe lequel de ces trois. Donc, vous avez en quelque sorte une condition satisfait à tous et remplissez n'importe quelle condition, puis vous pouvez avoir un mélange de ces deux là où vous pourriez dire : de ces conditions doivent être remplies. Il y a un certain nombre de ces possibilités. Vous pourriez même dire que la condition est : « Eh bien, leur beignet préféré, la lettre doit commencer par « S ».

04:35 PR : Et ce que j'essaie de dire, c'est que lorsque l'information est vraiment, vraiment structurée, vous pouvez poser des questions à la base de données car la base de données sait en quelque sorte à quoi s'attendre et il y a certaines règles pour ce que ces requêtes pourraient be et la base de données est vraiment bonne pour… Et le système est vraiment bon pour sortir cette information parce que tout est très, très structuré. Donc, je suppose que la fin de tout cela, c'est que lorsque vous configurez votre CRM, la moyenne détermine en quelque sorte quelles informations doivent aller où autant qu'elles le peuvent afin que les informations puissent être extraites très facilement plus tard.

05:07 AS : Oui, et je pense qu'une autre partie de cela, et corrigez-moi si je me trompe, c'est là où les intégrations entrent en jeu. Donc, si vous avez des formulaires de connexion comme vous en parliez avec la façon dont nous avons Benchmark ou différents aimants principaux tout au long, il va structurer ces données dans le bon format lorsque vous connectez ces autres applications tierces à votre CRM.

05:24 PR : Oh, mon Dieu. Oui. Andy, c'est un excellent point. D'accord, disons par exemple que vous devez vous inscrire sur les formulaires Google. Nous avons donc besoin d'une intégration du CRM avec les formulaires Google, comme nous le faisons avec les e-mails de référence et quelques autres sociétés non-référencées, n'est-ce pas ? Mais disons simplement que vous dites : « Très bien. Eh bien, dans ce formulaire, le formulaire l'appelle prénom, mais dans le CRM, nous l'appelons… Comme je l'ai dit, nous l'appelons également prénom afin que vous puissiez mapper prénom sur prénom, n'est-ce pas ? Nom de famille au nom de famille. Mais alors peut-être que vous avez quelque chose où vous dites OK, eh bien nous avons ce formulaire a quelque chose qui dit numéro de téléphone, dans le CRM il dit numéro de téléphone principal donc mappons-le d'ici à là. Ainsi, lorsque vous vous connectez à ce formulaire, il y aura un processus de mappage où vous verrez les champs qui existent dans le CRM et les champs qui proviennent de l'intégration que vous êtes. Et vous pouvez dire d'accord, regardez cette fente va avec cette fente et cela va avec cette fente. Et parce que les choses sont des structures, il est très, très facile pour ces choses d'aller ensemble. Et cela ne veut pas dire qu'il n'y a pas d'autres façons de faire les choses, mais nous y reviendrons plus tard.

06:22 AS : Voilà. Alors merci à tous d'avoir écouté et nous aborderons ces autres choses plus tard si vous continuez à vous connecter. Merci encore.