Automating Student Onboarding via WhatsApp in SugarCRM

Northbeam Technologies — Fri, 26 Jun 2026 07:41:34 +0000

A multi-step conversation engine that captures leads and creates CRM records automatically — no staff required.

The Problem

When prospective students first contact the school via WhatsApp, staff had to manually collect their details and create a record in SugarCRM by hand. Leads that arrived outside business hours were simply missed or delayed — there was no way to capture them without a person in the loop.

The school was already using Twilio for outbound WhatsApp messages from SugarCRM, but replies from unknown numbers went nowhere.

What We Built

A multi-step conversation engine built directly into SugarCRM. When an unknown number sends a WhatsApp message, the system:

Intercepts the message via a Twilio webhook
Checks whether the phone number already exists as a student record
If yes → routes to the existing follow-up flow (no change)
If no → starts a guided intake questionnaire, validates each answer, and creates the student record automatically

Zero admin involvement for new contacts.

How It Works

Key Technical Decisions

State machine, not a script.

Each conversation is a session with a current_step pointer. Questions can be reordered, toggled, or mapped to any CRM field without changing code. Admins manage the question bank directly from SugarCRM's UI.

Phone number normalization.

The system normalizes Israeli, US, and Vietnamese number formats before matching — preventing duplicate records from format variations like +1-555... vs 001555....

Media guard.

If a student sends a photo or voice note, the system replies politely that only text is supported and automatically resends the current question.

Partial completion handling.

If a student stops mid-flow, automated reminders go out at 2h and 24h. If minimum data (name + phone) is collected and the student still doesn't respond, a partial record is saved so the lead isn't lost.

Multi-number support.

Multiple Twilio sender numbers can be registered in SugarCRM. Each conversation session locks to the number the student originally contacted.

What Changed After Launch

✅ Student record creation from WhatsApp is fully automated for new contacts
✅ Leads outside business hours are captured without any staff intervention
✅ Admins can view full chat history, manually resume sessions, or override any step from inside SugarCRM
✅ The existing outbound messaging workflow for known students is completely unchanged

Stack

PHP — core logic and SugarCRM custom modules
SugarCRM — custom modules for session management, question bank, and student records
Twilio WhatsApp API — inbound webhook + outbound messaging
MySQL — session state persistence

The main lesson here: WhatsApp bots don't need a separate platform. If your CRM already has a webhook endpoint and an API, you can build the conversation engine right inside it — and keep everything in one place for your team.

Originally published on northbeam-tech.com

Client-Side Video Transcoding with FFmpeg.wasm — No Server Required

Northbeam Technologies — Wed, 24 Jun 2026 08:02:20 +0000

The problem

The Kolel Creator Dashboard lets educators and rabbis upload video lessons directly from their browser. Creators record on phones, tablets, and cameras — producing files in every format imaginable: .mov, .webm, .avi, .mkv.

Our Google Cloud Video Transcoder pipeline expects MP4 input. The original solution was a dedicated pre-upload server that re-encoded every file before it hit cloud storage. One more service to deploy, monitor, and pay for.

We needed a way to normalize the format before the file ever left the creator's machine.

The solution: FFmpeg running inside the browser

We integrated @ffmpeg/ffmpeg into the Vue 2 upload component. When a creator picks a non-MP4 file, the browser:

Downloads the FFmpeg WASM core (~30 MB, cached after first load)
Transcodes the file to MP4 inside a Web Worker
Uploads the resulting blob directly to a GCS Signed URL

The Rails API and the downstream transcoding pipeline never see anything other than a clean MP4.

The core transcoding function

import { createFFmpeg, fetchFile } from '@ffmpeg/ffmpeg';

async convertToMp4(file) {
  const supportedTypes = ['video/mp4', 'video/mov', 'video/m4v'];
  if (supportedTypes.includes(file.type)) {
    return; // already compatible — skip transcoding
  }

  const ffmpeg = createFFmpeg({
    log: true,
    corePath: 'https://unpkg.com/@ffmpeg/core@0.10.0/dist/ffmpeg-core.js',
  });

  if (!ffmpeg.isLoaded()) {
    await ffmpeg.load();
  }

  const fileName = file.name;
  const outputFileName = 'output.mp4';

  ffmpeg.FS('writeFile', fileName, await fetchFile(file));
  await ffmpeg.run('-i', fileName, outputFileName);

  const data = ffmpeg.FS('readFile', outputFileName);
  this.selectedFile = new Blob([data.buffer], { type: 'video/mp4' });
}

A few things worth noting:

We pin a specific CDN version of @ffmpeg/core so the WASM binary is cached in the browser after the first upload session. Repeat visitors pay zero load cost.
We bail early for common formats (mp4, mov, m4v). Running FFmpeg.wasm on a file that's already compatible wastes time and memory.

Uploading without exposing credentials

The browser never holds GCS credentials. The Rails API generates a short-lived Signed URL for the specific file path, then the browser PUTs directly to GCS:

async uploadFileToSignedUrl(signedUrl, selectedFile) {
  await axios.put(signedUrl, selectedFile, {
    headers: { 'Content-Type': selectedFile.type },
  });
}

async prepareVideoUpload() {
  this.loading = true;
  await this.getSignedUrl();
  await this.uploadFileToSignedUrl(this.signedUrl, this.selectedFile);

  if (this.pickedThumbnail) {
    await this.getImageSignedUrl();
    await this.uploadFileToSignedUrl(this.thumbnailSignedUrl, this.pickedThumbnail);
  }

  this.addVideo(); // notify Rails API to create the video record
}

Results

Before	After
Pre-upload transcoding microservice	Removed entirely
Format errors reaching the pipeline	Zero
GCS credentials in the browser	Never
Upload experience for MP4/MOV users	Unchanged

Key takeaways

FFmpeg.wasm is production-ready for this use case. The WASM core is large, but browser caching makes repeat sessions fast.
Signed URLs are the right pattern for direct browser-to-cloud uploads. No credentials ever leave your server.
Always allow-list known-good formats before invoking WASM — it saves real time for the majority of your users.

Stack

Vue 2 · @ffmpeg/ffmpeg 0.10 · @ffmpeg/core (WebAssembly) · Google Cloud Storage · GCS Signed URLs · Google Cloud Video Transcoder · Rails 7 · Axios

Originally published on the Northbeam Technologies blog.

DEV Community: Northbeam Technologies

Automating Student Onboarding via WhatsApp in SugarCRM

The Problem

What We Built

How It Works

Key Technical Decisions

What Changed After Launch

Stack

Client-Side Video Transcoding with FFmpeg.wasm — No Server Required

The problem

The solution: FFmpeg running inside the browser

The core transcoding function

Uploading without exposing credentials

Results

Key takeaways

Stack