CRM, Leads, Campaigns & Portals

1. Companies and Contacts

The accounts and people of CRM

SamvraCore's CRM is organised around two linked record types. Companies, on the CompaniesListPage, represent accounts and carry attributes including industry, lifecycle stage, and a B2B or B2C type. Contacts, on the ContactsListPage, represent individual people and are linked to companies, so the system can relate a person to the organisation they belong to.

This structure reflects how business relationships actually work: an organisation deals with companies, and within each company there are specific people to communicate with. Linking contacts to companies lets the CRM present a coherent picture of an account and everyone associated with it.

Attributes that give companies meaning:

• Industry — classifies the account by sector.
• Lifecycle stage — indicates where the account sits in its relationship with the business.
• B2B or B2C type — distinguishes business customers from individual consumers.

A typical use is to create a company record for a new account, set its industry, lifecycle stage, and type, and then add the relevant contacts linked to that company. From there the CRM can capture interactions with those contacts and feed the broader selling process. Companies and contacts therefore form the foundation on which leads, interactions, and campaign targeting all build.

2. Interactions

Recording every touchpoint

Interactions capture the communications that occur between the organisation and its contacts. SamvraCore records interactions as calls, emails, meetings, and notes, implemented in the backend interaction_usecase.go. Together these types cover the common ways a business engages with the people in its CRM.

Keeping a history of interactions is valuable because it turns scattered conversations into a durable record attached to the relationship. Rather than relying on individual memory, the team can see what was discussed, when, and through which channel.

The recognised interaction types are:

• Calls — phone conversations with a contact.
• Emails — email correspondence.
• Meetings — scheduled or held discussions.
• Notes — free-form observations about the relationship.

Because contacts are linked to companies, interactions recorded against contacts contribute to a fuller account-level view of engagement. A typical pattern is that after a sales call, the representative logs the call as an interaction with a short note, and when follow-up emails or meetings occur, those are logged too. Over time this builds a timeline of the relationship that supports both day-to-day selling and later analysis of how an account was nurtured.

3. Leads and Qualification

Handling early interest

Lead Management in SamvraCore is handled on the LeadsListPage, backed by lead_usecase.go. Leads represent early, unqualified interest that the business wants to assess before investing significant effort. The module captures lead sources, a qualification status, and a disqualify flow.

The elements of lead handling:

• Sources — where the lead came from, supporting analysis of which channels generate interest.
• Qualification status — a status that reflects how far a lead has been assessed as a genuine opportunity.
• Disqualify flow — an explicit path for marking a lead as not worth pursuing.

Tracking sources matters because it reveals which marketing and sales channels are actually productive. Qualification status gives structure to the judgement of whether a lead is worth advancing, and the disqualify flow ensures that dead-end leads are cleanly set aside rather than lingering indefinitely.

A typical flow is that a lead arrives with a recorded source, is assessed and given a qualification status as information is gathered, and either advances toward becoming a genuine sales opportunity or is run through the disqualify flow. Because leads sit upstream of the companies, contacts, and sales pipeline, disciplined lead management keeps the rest of the CRM focused on prospects that merit attention.

4. Campaigns

Coordinating marketing outreach

Campaigns, on the CampaignsListPage, let the organisation plan and run multi-channel marketing outreach. Each campaign is defined with a type, a channel, target segments, and an expected close. This structure ties marketing activity to specific audiences and expected outcomes rather than leaving it undirected.

The defining attributes of a campaign:

• Type — the kind of campaign being run.
• Channel — the medium through which it reaches its audience, reflecting the multi-channel nature of the module.
• Target segments — the audience segments the campaign is aimed at.
• Expected close — the anticipated outcome tied to the campaign.

To judge effectiveness, SamvraCore records Campaign Metrics including bounce rate, click rate, opened, clicked, and sent. These metrics describe how recipients responded to the outreach. Beyond raw engagement, the module provides ROI Analysis and Attribution, connecting campaign activity to its business return.

A typical flow is to define a campaign with its type and channel, direct it at one or more target segments, send it, and then review the metrics such as sent, opened, clicked, click rate, and bounce rate. ROI analysis and attribution then relate the campaign to results, helping the team understand which outreach actually drove value. Campaigns thus depend on segments to define who is reached and on templates to define what is sent.

5. Audience Segments and Email Templates

Defining who is reached and what is sent

Campaigns rely on two supporting features. Audience Segments, on the SegmentsListPage, define the groups a campaign targets. Segments can be static or criteria-driven dynamic, and dynamic matching is case-insensitive, implemented in segment_criteria.go. A static segment is a fixed list, while a dynamic segment is defined by criteria so its membership follows the data.

Email Templates, on the TemplatesListPage, define the content that campaigns send. Each template includes a subject, an HTML body and a plain-text body, template-data expressed as JSON, a set of available template variables, and a preview capability.

Template building blocks:

• Subject — the email subject line.
• HTML and plain-text body — two renderings so recipients receive appropriate content.
• Template-data JSON and variables — allow content to be personalised through available variables.
• Preview — lets the author see the result before sending.

The division of labour is clear: segments answer who receives a campaign, and templates answer what they receive. A typical flow is to build a dynamic segment from criteria so it automatically includes matching contacts, design an email template with both body formats and the needed variables, preview it, and then target the campaign at the segment using that template. This combination makes campaign outreach both targeted and consistent.

6. The Customer Portal

Customer self-service

SamvraCore provides a Customer Portal under frontend/src/portal/customer, served by the backend customer_portal_controller.go. The portal has its own separate authentication and dashboard, and access can be shared via a portal URL. For sign-in, it offers magic link passwordless authentication, so customers log in through a link rather than managing a password.

Through the portal a customer can self-serve a range of account activities:

• View invoices and download PDFs — access their billing documents directly.
• Track orders and shipments — follow the progress of what they have ordered.
• View payment history — see payments they have made.
• Generate account statements with date ranges — produce a statement for a chosen period.

Offering these capabilities as self-service reduces the burden on internal staff while giving customers immediate access to their own information. Because the portal has separate authentication, customer access is isolated from internal ERP users.

A typical customer journey is to receive a magic link, sign in to the portal dashboard, view and download an invoice PDF, check the status of a pending shipment, and generate an account statement for a recent date range. The portal thus turns routine account queries into actions the customer can complete independently, backed by the same order, shipment, invoice, and payment data held in the ERP.

7. Vendor Portal and Portal Administration

Vendor collaboration and internal control

The Vendor Portal lives under frontend/src/portal/vendor and is served by vendor_portal_controller.go. Like the customer portal it has separate authentication, its own dashboard, and share-via-portal-URL access, but it is invitation-only: a vendor must accept an invitation and set up an account before using it.

Vendor-facing capabilities include:

• View purchase orders assigned to the vendor.
• Acknowledge purchase orders with expected delivery dates.
• Track payment status for their invoices.
• Upload documents such as a W-9, insurance certificates, and invoices, which pass through a document review workflow moving from pending to approved or rejected.

Overseeing both portals is Portal Administration, exposed on the PortalSettingsPage and served by portal_admin_controller.go. Administration covers portal URLs, allowed domains, and portal-user provisioning. Internal staff use it to enable or disable portal access per customer or vendor, send portal invitations, review and approve or reject vendor documents, manage pending invitations, and revoke portal user access.

A typical administrative flow is to send a vendor an invitation, which the vendor accepts to set up their account. The vendor then views and acknowledges assigned purchase orders with expected delivery dates and uploads required documents, which internal staff review and approve or reject. Administration keeps this collaboration controlled through domain restrictions, provisioning, and the ability to revoke access.