Skip to main content
The Korint platform automatically sends email notifications throughout the insurance policy lifecycle. These emails are triggered by specific business events and delivered to the appropriate recipients based on their role in the transaction.

​
Email Triggers

Korint supports two distinct approaches to sending emails, each serving different operational needs within the platform.

​
1. Event-Driven Emails

The platform automatically triggers emails when business events occur across various services. This event-driven approach ensures that stakeholders receive timely notifications without manual intervention. When a significant business event happens—such as a policy being signed, a payment being processed, or a claim being submitted—the system listens to these events and automatically sends the appropriate email to the relevant recipients. This automated approach covers critical business moments including policy signature confirmations, payment notifications, claim status updates, mid-term adjustment (MTA) confirmations, and derogation approval workflows. The event-driven model ensures consistency and reliability in customer communications while reducing the operational burden on staff.

​
2. Configurable Event-to-Template Mapping

The platform provides a flexible configuration system that allows administrators to define custom business events and map them to specific email templates. This approach enables each insurance product or brokerage firm to establish their own communication workflows based on their unique business processes. Custom events can be created for any business scenario—such as broker invitations, manual customer notifications, derogation approvals, or product-specific milestones. Once a custom event is defined, the platform can be configured to map that event to one or more email templates, specifying which recipients should receive the notification and what data should be included in the email content. This configuration-driven approach ensures that as business needs evolve, new communication workflows can be established without requiring code changes. The platform maintains a registry of event-to-template mappings, allowing administrators to manage the entire email communication strategy through configuration rather than manual intervention.
When a policy document is signed, the Signature Service emits a PolicySigned event. The email system listens to this event and automatically sends a confirmation email to the policyholder.
// Event emitted by Signature Service
{
  eventType: 'Policy Signed',
  policyId: 'pol_123',
  customerId: 'cust_456',
  signedAt: '2025-10-08T10:00:00Z'
}

// Email automatically triggered
// → Sends policy confirmation email to customer

​
Recipients

​
Custom Role-Based Distribution

Email recipients are determined through a flexible role-based system that allows each brokerage firm to define custom roles for their team members. The platform identifies who should receive emails by matching the business event with the configured recipient roles, ensuring that the right people are notified at the right time. Each brokerage firm can establish its own organizational structure with custom roles such as administrators, commercial agents, managers, or any other role that fits their business model. When an email trigger is configured, it specifies which roles should receive that particular type of notification. The system then automatically identifies all brokers within the relevant brokerage firm who hold those roles and sends them the email. This approach provides flexibility for different organizational structures while maintaining centralized control over communication workflows. For example, a policy signature event might trigger emails to brokers with administrative roles, while a claim submission might notify brokers with claims management roles. The system also supports hierarchical structures, allowing emails to be sent to wholesale brokers (parent brokerage firms) or retail brokers (child brokerage firms) based on the business context.
When a policy is signed this product, the system sends an email to brokers with specific roles within the brokerage firm.Email Configuration:
{
  trigger: 'Policy Signed',
  templateId: 'customer_contract_signed',
  sendTo: [
    {
      recipient: 'Broker',
      roles: ['Broker Retail', 'Broker Admin']
    }
  ]
}
Result: If the brokerage firm has five brokers—one with the Broker Admin role, two with the Broker Retail role, and two with the Broker Wholesale role—only the three brokers with Broker Admin or Broker Retail roles receive the policy signature confirmation email. The two brokers with Broker Wholesale roles do not receive this notification as they are not included in the configured recipient roles.

​
Content Generation

​
Dynamic Data Assembly

The email system dynamically generates personalized content by retrieving data from across the platform when an email is triggered. Using a template-based approach, placeholders are automatically replaced with relevant information at the time of sending. Available Data Sources:
  • Policy Information: All details related to the insurance policy, including coverage, premiums, dates, and current status
  • Customer Profile: Complete customer information including personal details and contact information
  • Brokerage Firm: Full brokerage firm details including company identity, location, contact information, and platform configuration
  • Financial Data: Payment and billing information, including payment methods, transaction history, and invoice details
  • Assets: Information about insured items such as vehicles, properties, or equipment
  • Claims: Claim status, reference numbers
This ensures every email is personalized, accurate, and contains exactly the information the recipient needs for that specific business event.

​
Use Cases

​
Example 1: Policy Signature Confirmation

When a customer completes the digital signature of their insurance policy, the system immediately sends a confirmation email to both the customer and the managing broker. This email serves as official acknowledgment that the policy is now active and legally binding. The customer receives an email with their policy number (e.g., POL-2024-05678), the effective date of coverage, a summary of their coverage including the insured assets, and the premium amount and payment schedule. Simultaneously, brokers with the appropriate roles (such as retail administrators or commercial agents) receive a notification that includes the customer’s name, policy number, and product type. This allows the broker to follow up with the customer, ensure they understand their coverage, and address any questions.

​
Example 2: Payment Failure Alert

When a scheduled payment fails—whether due to insufficient funds, an expired card, or a declined transaction—the system triggers an immediate notification to the customer and the broker. This email is time-sensitive because it may affect the customer’s coverage status. The customer receives an email explaining that their payment of €127.50 for policy POL-2024-05678 could not be processed. The email specifies the payment method that was attempted (e.g., “Visa ending in 4532”), the reason for the failure if available, and the date by which payment must be received to avoid a lapse in coverage. It includes a prominent call-to-action button linking directly to the payment page where they can update their payment method or retry the payment. The email also provides alternative payment options, such as bank transfer details if applicable, and the broker’s contact information for assistance. The broker receives a parallel notification that includes the customer’s name, policy number, failed payment amount, and the number of days remaining before the policy enters a grace period or lapses. This enables the broker to proactively reach out to the customer, offer assistance, and help resolve the payment issue before coverage is affected. The broker’s email includes a link to the customer’s payment history and policy status.

​
Example 3: Mid-Term Adjustment (MTA) Approval

When a customer requests a change to their policy during the coverage period—such as adding a new vehicle to their auto insurance or updating their address—the system processes the modification and sends detailed notifications once the change is approved. The customer receives an email confirming that their policy modification has been processed. The email clearly outlines what changed: for example, “Your new vehicle, a 2024 Tesla Model 3 (VIN: 5YJ3E1EA1PF123456), has been added to your policy effective March 15, 2025.” It includes the updated premium amount, showing both the previous monthly premium (€95.00) and the new premium (€142.50), along with an explanation of the pro-rated adjustment for the current billing period. The email provides a link to view the updated policy schedule and download an amended policy document reflecting the changes. The broker receives a notification that the MTA has been completed, including details of the modification, the premium adjustment, and confirmation that the customer has been notified. This keeps the broker informed of all policy changes and allows them to follow up if needed.