sql >> Database >  >> RDS >> Database

Deel 3 – Klanten, oproepen en vergaderingen

Eerder in deze serie hebben we het databasemodel van SuiteCRM in Vertabelo geïmporteerd en laten zien hoe je de functies van Vertabelo kunt gebruiken om het te organiseren. In dit artikel zullen we zien hoe algemene CRM-gegevens worden opgeslagen in de database. We zullen ook de aannames controleren die in deel 2 zijn gemaakt over de relaties tussen tabellen en hun functies. Indien nodig passen we het model aan.

Wat hebben we momenteel?

In deel 1 hebben we SuiteCRM lokaal geïnstalleerd met behulp van het Bitnami-installatiepakket. Na succesvol inloggen, ziet het hoofdscherm van SuiteCRM er als volgt uit:

De SuiteCRM-database genaamd "bitnami_suitecrm" is toegankelijk op locatie http://127.0.0.1/phpmyadmin. Bedenk dat het model 201 tabellen heeft.

We hebben deel 2 van deze serie afgesloten met het model dat als volgt is ingedeeld:




Basisvereisten voor een CRM

Een CRM moet ons in staat stellen om onze klanten bij te houden en de contacten (oproepen, meetings, enz.) die we met hen hebben bij te houden.

Klanten staan ​​centraal in elk CRM-systeem. We moeten hun basisorganisatiegegevens (naam, adres, omzet, aantal werknemers) en hun contactgegevens (telefoon, mobiel, e-mail, website en misschien zelfs sociale accounts) opslaan. We moeten ook administratieve gegevens bijhouden, zoals wanneer en door wie hun administratie is toegevoegd of bijgewerkt in het systeem.

Als we denken aan klantgerelateerde acties, denken we meestal aan telefoontjes en vergaderingen. We kunnen ook andere acties ondernemen waarvoor geen contact met de klant nodig is:controleren of een probleem is opgelost, of er een betaling is gedaan, dat soort dingen. We willen eerdere acties bijhouden, maar we hebben ook de mogelijkheid nodig om toekomstige evenementen te plannen. Verder slaan we de begin- en eindtijden van acties op, wie actiegegevens heeft ingevoerd en bijgewerkt, wie die specifieke actie heeft gestart en wie er de leiding over heeft.

Natuurlijk zijn er nog een heleboel andere dingen - zoals eerder verkochte producten en diensten en potentiële nieuwe verkopen - die we ook aan een CRM kunnen toevoegen. Maar in dit artikel zullen we ons concentreren op hoe SuiteCRM klantgegevens, oproepen en vergaderingen opslaat.

Klanten beheren

Klantorganisaties worden accounts genoemd in SuiteCRM. Dit is wat de Nieuw account maken scherm ziet er als volgt uit:

En zo ziet de "accounts"-tabel in de database van SuiteCRM eruit:

Binnen de accounts tabel, attributen winkelinformatie ingevoerd in Nieuw account aanmaken scherm:

  • Basis klantgegevens:name , description , industry , annual revenue ,“rating , ownership , employees , ticker symbol
  • Contactgegevens:phone_fax , factuuradreskenmerken, verzendadreskenmerken, phone_office , phone_alternate , website
  • Wijzigingen in klantgegevens in de CRM:created_by , modified_user_id , assigned_user_id , date_entered , date_modified en deleted .

De meeste van deze attributen zijn van het type varchar omdat het CRM door de gebruiker ingevoerde gegevens van elk mogelijk type moet kunnen opslaan.

De accounts table is verbonden met vele andere tabellen in de SuiteCRM-database. Alle relaties zijn vastgesteld volgens de veronderstellingen die zijn opgetekend in deel 2 van deze serie.

Accounts in SuiteCRM zijn in feite een lijst met klanten. Ze zijn gerelateerd aan veel andere tabellen in het systeem:contacts , opportunities , bugs , cases .

In SuiteCRM-spreken, contacten zijn echte mensen met wie we namens hun organisatie praten (onthoud, in CRM-taal worden deze organisaties "accounts" genoemd). U kunt een nieuw contact aan een account toewijzen, zoals hieronder weergegeven:

De gegevens van de persoon worden opgeslagen in de contacts tafel. De account_contacts tabel stelt ons in staat om veel contacten aan een bepaald account te koppelen.

Kansen binnen SuiteCRM zijn geschatte verkoopmogelijkheden. Ze zijn gebonden aan de verkoopfase. De opportunities en account_opportunities tabellen worden gebruikt om gegevens op te slaan over meerdere opportunities met betrekking tot één account.

Zoals je uit hun naam zou kunnen raden, zijn de bugs en accounts_bugs tabellen slaan gegevens op over problemen met bepaalde accounts. De SuiteCRM-module stelt ons ook in staat om oplossingen in te voeren en buggeschiedenissen bij te houden. Bugs zijn gerelateerd aan calls , contact , cases en andere tabellen.

De module "cases" wordt gebruikt om servicegerelateerde problemen in te voeren en te volgen. Nadat we een nieuwe case hebben toegevoegd, kunnen we bugs toevoegen die verband houden met die case.

Oproepen

Elk CRM-systeem slaat informatie op over oproepen naar klanten; SuiteCRM is niet anders. Om een ​​nieuwe oproep toe te voegen, klikken we op Activiteiten --> Oproepen en vul de benodigde gegevens in. We voegen een nieuwe oproep toe en koppelen deze aan een bestaande account en gebruiker in ons systeem.

Dit is wat de roept sectie in de database ziet er als volgt uit:

In de calls tabel, kunnen we enkele van dezelfde kenmerken zien als in de accounts tafel. De attributen created_by , modified_user_id en assigned_user_id verwijzen naar de gebruiker(s) die deze oproep hebben ingevoerd, gewijzigd of aan de oproep zijn toegewezen. Het parent_type en parent_id paar geeft aan naar welke tabel wordt verwezen en de primaire sleutelwaarde voor die tabel. De meeste andere kenmerken spreken voor zich.

Dezelfde structuur, met behulp van een veel-op-veel-relatie, wordt gebruikt om oproepen te verbinden met gebruikers, leads en contacten.

Na het klikken op de Opslaan knop, kunnen we een nieuw oproeprecord zien in onze Oproepen lijst. Nu gaan we in de database kijken, met name in de calls en calls_users tabellen.



In de calls tabel kunnen we zien dat “parent_type” =Accounts en dat de id in de parent_id veld is de account-ID. Binnen de database zijn er een paar tabellen die hetzelfde attribuut gebruiken om verbinding te maken met een van een handvol andere tabellen. Terwijl parent_id bevat de waarde van de primaire sleutel in de tabel waarnaar wordt verwezen, parent_type geeft aan met welke tafel we verbinding maken.

Natuurlijk, in de calls_users tabel zullen we die oproep relateren aan een toegewezen gebruiker.


Vergaderingen

De "Vergaderingen en leads ” sectie is de groep tabellen die wordt gebruikt om gegevens op te slaan met betrekking tot vergaderingen en leads. Hoewel het duidelijk is wat de vergadergegevens kunnen zijn, leads verwijzen naar de potentiële interesse van klanten in onze producten en diensten. Later zullen we die leads gebruiken en ze relateren aan opportunities, calls en meetings.

We zullen zien dat enkele algemene regels voor het benoemen van velden in de meetings tabel en voor het verbinden van vergaderingen met contacten, leads en gebruikers worden in deze sectie toegepast.

Net als bij oproepen kunnen ook vergaderingen worden toegewezen aan gebruikers en gerelateerd aan klanten. We gaan naar een nieuwe vergadering door te klikken op Activiteiten --> Vergaderingen --> Vergadering plannen .

De vergadergegevens worden, eenmaal ingevoerd, opgeslagen in SuiteCRM; we kunnen het bekijken in de lijst met vergaderingen. Net als bij oproepen kunnen vergaderingen worden toegewezen aan accounts, contacten, taken, kansen, bugs, cases, leads, projecten, projecttaken en doelen.

In de database, de meeting tabel bevat gegevens over de nieuw toegevoegde vergadering. Het parent_type en de parent_id attributen worden op dezelfde manier en voor hetzelfde doel gebruikt als de calls gegevens.



De meetings_users table slaat informatie op over de gebruikers die aan een bepaalde vergadering zijn toegewezen.



Primaire sleutels zijn willekeurig gegenereerde hash-waarden. Dit stelt ons in staat om unieke waarden te hebben voor elke primaire sleutel in de hele database, niet alleen in elke tabel. Dit is vooral handig wanneer we hetzelfde attribuut gebruiken als een externe sleutel voor veel verschillende tabellen. Eén kenmerk bevat de sleutelwaarde, terwijl een ander de naam van de tabel waarnaar wordt verwezen, bevat. Dit biedt veel meer flexibiliteit - meer dan systemen die verschillende real-life zakelijke situaties dekken, over het algemeen nodig hebben.

In deel 4, waarmee deze serie wordt afgesloten, gaan we dieper in op de rest van SuiteCRM, inclusief campagnes, projecten, kansen en documentbeheer.


  1. Installatie van een EBS 12.2 Vision-instantie uitvoeren

  2. ORA-4031 fouten met Direct NFS

  3. Tabel gewaardeerde functies in ORACLE 11g? (geparametriseerde weergaven)

  4. MariaDB Datum- en tijdseenheden