JEMs CRM: Drupal
Bulk SMS for Close CRM

A small sales team lives or dies by how fast it follows up. Text a lead while they are still interested and you get a reply; wait a day and the lead has moved on. The team behind JEMs CRM already understood that. Their problem was that the tool they used to send those texts belonged to someone else, and that access could disappear overnight.

JEMs CRM is a private web app that lets a small sales team send bulk SMS to leads stored in Close CRM. A staff member picks a Close Smart View, such as initial outreach or follow-up, chooses one of their Close SMS templates, previews the leads with details like their last activity date, and sends. Messages go out through Close’s own built-in SMS line, fifteen at a time, so every text is logged against the lead in Close exactly as if a person had typed it.

Put simply, the app turns a slow manual chore into one decision. Pick a Smart View, pick a template, and fifteen leads are texted in a single click, then an autopilot repeats that every fifteen minutes through business hours. The team owns the code, runs it on their own domain, and no longer depends on anyone keeping a login active.

The Starting Point: Owning the Outreach, Not Borrowing It

The team had a workflow that worked, but it ran on a former business coach’s server. Rebuilding it as something the business owns meant pinning down exactly what the outreach had to do, and what rules it had to respect so the phone line stayed safe.

• End the dependence on someone else’s tool. The bulk SMS page belonged to a third party whose access could be pulled at any time, stopping outreach in its tracks. The business needed its own.
• Replace slow manual texting. Sending templated texts to leads one by one inside Close takes hours and invites mistakes. The team wanted to text a whole Smart View in one action.
• Respect the sending limit. To keep the number from being flagged, no more than fifteen texts can go out at once, with a fifteen-minute gap before the next batch.
• Run outreach during business hours. Texting had to be able to run on its own, for example from 9am on weekdays, with the option to switch off certain days or pause it entirely.
• Keep it staff-only. Only a few employees should reach the page, with logins separate from their Close accounts.
• Log everything in Close. Each text had to be recorded against its lead so Smart View filters move those leads on to the follow-up stage automatically.

The Build: From Smart View to Sent, in One Click

A staff member logs in and opens the bulk SMS page. The first drop-down lists their Close Smart Views, the second lists their Close SMS templates, and the page shows a preview of the message beside the leads it will reach. Making that one page read Smart Views, templates, and lead activity reliably from Close, then send in controlled batches, is the substance of the custom Drupal development company work behind the app. A send runs in a set order:

1. The staff member logs in with their own account, separate from Close.
2. They choose a Close Smart View, such as initial outreach or follow-up.
3. They choose one of their Close SMS templates.
4. The page previews the message and the leads in that view, with each lead’s last activity date.
5. One click sends the texts through Close’s built-in SMS, fifteen at a time.
6. Every message is logged in Close, so the Smart View filters move those leads on to the next stage.

For hands-off outreach, the autopilot sends fifteen texts every fifteen minutes inside a set window. Staff choose the start and end time, pick which weekdays it runs on, and can disable a single day or the whole schedule in a click. An admin creates staff logins in a simple panel, connects the Close API key once, and a reports view shows how many messages went out by day or week.

Technical Architecture

JEMs CRM is a custom Drupal application that sits between the staff and the Close CRM API. The hard part was never the single page. It was reading Smart Views and templates reliably from Close, sending in controlled batches, and running a scheduler on shared hosting that keeps going without anyone watching.

• Drupal custom module. Drupal handles secure users and roles; a custom module holds all the Close-specific logic, from loading a Smart View to queuing a send.
• Close REST API client. A service in the module reads Smart Views, their leads, SMS templates, and lead activity from Close, and sends texts back through Close’s SMS endpoint using the team’s existing numbers. Getting that integration solid is the kind of API development that decides whether a tool like this is trustworthy.
• Batch send engine. Sends are split into batches of fifteen and queued, with a fifteen-minute gap enforced between batches for both manual and scheduled sends.
• Queue API and cron. Drupal’s Queue API with cron wakes the workers, sends only inside the chosen window, and retries where needed.
• MySQL. Users, schedules, and send history live in the database, which also feeds the reports view.
• Hosting and front end. A simple Drupal theme gives staff a functional interface, and the app runs on the client’s own Hawk Host hosting with their GoDaddy domain pointed at it.

The piece worth engineering carefully was the join between the scheduler and the live Close account. Batches that respect the limit, a queue that recovers on its own, and a cron window that fires in the client’s own time zone are what let the team trust an autopilot to text leads while nobody is looking.

Challenges Solved

The original page belonged to someone else, so only its screens and behaviour were visible. The workflow was mapped from the live page and the Close API documentation, then rebuilt from scratch, keeping what the team relied on and adding scheduling and reports. Testing was its own problem: Close protects logins with one-time codes and the texts are real, so testing used dedicated test leads and a test Smart View, sending to the team’s own numbers and always inside the fifteen-per-fifteen-minutes limit, so no real lead was ever contacted by mistake. The client’s first choice of hosting could not run custom PHP or background jobs, so suitable shared hosting was recommended, the existing domain pointed to it, and cron and the queue set up so the autopilot runs reliably. Soon after go-live, direct sends paused because the background queue had stopped on the server; it was restarted, put under supervision so it recovers automatically, and the fix was covered by the post-launch support period.

That pattern of owning the system rather than renting it is what SaaS and startup sales teams need most, because an outreach engine that someone else can switch off is a business risk, not an asset.

The Result

The team now has a bulk SMS tool it fully owns, deployed live on its own domain and hosting since August 2024, with both milestones approved and a review left after go-live. Staff pick a Smart View and a template and text fifteen leads in one click; autopilot repeats it through business hours; every text is logged in Close against its lead; and the sending limit protects the phone line whether a person or the scheduler is sending. Outreach that used to depend on a third party now runs on code the business controls.

The build works because it was designed for reliability and ownership, not just to copy a page. If you are planning something similar, you can hire Drupal developers who have built this Close-to-SMS pipeline on shared hosting, or tell us about your CRM workflow and we will map your Smart Views and sending rules to a tool you own outright.

Frequently Asked Questions

What does JEMs CRM do?

It is a private Drupal web app that sends bulk SMS to leads stored in Close CRM. Staff pick a Close Smart View and an SMS template, preview the leads, and send fifteen texts in one click through Close’s built-in SMS, with every message logged against the lead in Close.

Why build it on Drupal instead of using the existing tool?

The original tool belonged to an outside party who could remove access at any time. Rebuilding it as a custom Drupal application on the client’s own domain and hosting means the business owns the code and its outreach no longer depends on anyone else keeping a login active.

How does the sending limit protect the phone number?

Both manual and autopilot sends are capped at fifteen texts per batch, with a fifteen-minute gap before the next batch. That pace keeps the line from being flagged for spam and makes sending predictable, no matter how large the Smart View is.

How does the autopilot work?

The autopilot sends fifteen texts every fifteen minutes inside a set time window on chosen weekdays, driven by Drupal’s Queue API and cron. Staff set the start and end times, pick the days, and can disable a single day or pause the whole schedule whenever they want.

Does every text still appear in Close?

Yes. Messages go out through Close’s own built-in SMS using the team’s existing numbers, so each text is recorded on the lead in Close. That keeps the team’s Smart View filters working and moves leads from initial outreach to follow-up automatically.