How a Payment-to-CRM Sync Cut Manual Work by 80% Across Four Medical Cannabis Clinics

A multi-clinic medical cannabis operator with four locations across the United States was running a payment verification and patient intake process that consumed hours of manual labor every single day. When a patient paid a consultation or subscription fee, staff had to watch for email notifications, read payment details, verify the payment status was “completed” and not “failed” or “pending,” search the DaySmart CRM for the patient, note the account with the payment, switch to IntakeQ to check if the intake form was filled correctly, then return to DaySmart to update the patient status and add a note. This cycle repeated for every payment, at every clinic, every day.

Doctors could only see patients when both payment and intake were complete. If staff missed a step, the patient showed up unprepared, the doctor could not proceed, and the clinic lost both revenue and trust. The operations manager spent his days checking what staff might have missed instead of building systems. The staff were buried in context switching between four different applications for a single transaction.

I built an n8n automation that connects Square payments, IntakeQ intake forms, and DaySmart CRM in real time. Now when a payment completes, the system verifies it, checks the intake form, updates the CRM, and posts a clean Slack alert — all within seconds. Staff no longer touch the verification loop. They just read the alert and move on.

The full n8n workflow architecture — from Square webhook to Slack alert, with branching logic for patient lookup and intake verification.

The Real Problem Was Not What They Thought

Surface: The client told me they needed their systems to “talk to each other.” They knew the workflow was slow and wanted someone to “connect the dots.”

Root: The real problem was a brittle, multi-system workflow that created five separate failure points for every single patient:

• Payment monitoring fatigue: Staff had to actively watch email inboxes for Square notifications, then manually read each one to confirm the payment status was “completed.” Failed, pending, or refunded payments looked similar enough that mistakes happened.
• Slow CRM lookups: DaySmart (formerly AppointmentPlus) was not built for speed. Searching by phone number or name took 30–60 seconds per lookup, and the interface was clunky.
• Intake form verification: After confirming payment, staff had to switch to IntakeQ, search for the same patient, and verify the intake form was complete and accurate. Incomplete forms meant the doctor could not see the patient.
• Status update loops: After verifying both payment and intake, staff returned to DaySmart to update the patient status and add a manual note. This meant three separate application logins for one patient.
• No single source of truth: There was no place to see, at a glance, which patients were fully ready for their appointment. The operations manager had to ask staff or check each system individually.

What It Cost to Do Nothing

Every manual cycle carried hidden costs that compounded across four clinics:

• Missed appointments: When staff missed an incomplete intake form or an unverified payment, the patient arrived at the clinic unprepared. The doctor turned them away. The clinic lost the consultation fee and the patient’s trust.
• Staff overtime: The verification workload scaled linearly with patient volume. More patients meant more manual checks, more context switching, and more overtime hours.
• Operations manager trapped in oversight: Instead of developing new systems, hiring, or expanding to new locations, the operations manager spent his day verifying that staff had verified payments and intake forms. This was a high-salary role doing clerical quality control.
• Doctor dissatisfaction: Doctors were showing up to appointments only to find patients who had not paid or had not completed intake. This wasted their time and eroded their relationship with the clinic.
• Reputation risk: In the medical cannabis space, patient trust is everything. A single missed appointment or billing error could lead to a negative review that deterred future patients.

The client knew the operations manager and staff were overworked. They did not realize how much of that workload was caused by a workflow that should have been automated years ago.

Technical Barriers That Made This Hard

• Cannabis industry restrictions: Because the client operates in the medical cannabis space, many mainstream payment processors, CRMs, and automation platforms refuse to work with them. Their options for software were already limited.
• Legacy CRM: DaySmart had a SOAP-style API with double-nested JSON responses, basic HTTP authentication, and no modern webhook support. It was not designed for real-time automation.
• Three separate systems with no native integrations: Square handled payments. IntakeQ handled intake forms. DaySmart handled patient records. None of them talked to each other.
• Staff familiarity: The staff had developed muscle memory with the existing systems. Any solution that required retraining or switching platforms would create friction and resistance.
• Multi-location complexity: Each clinic had its own Square account, its own DaySmart instance, and its own Slack channel. The automation had to handle all four without mixing up patient data.
• Payment status ambiguity: Square notifications included multiple statuses — completed, failed, pending, refunded. Staff had to manually distinguish these. An automated system needed to handle each status correctly.

Finding the Real Bottleneck

Before building anything, I spent three days embedded in the client’s operations:

1. Workflow shadowing: I sat with the operations manager and watched the full payment-to-intake cycle from Square notification to DaySmart update. I timed each step and counted the number of application switches.
2. Email analysis: I reviewed one week of Square payment notifications to understand volume, timing patterns, and the rate of failed or pending payments that staff had to filter out.
3. CRM audit: I tested DaySmart’s API directly, documenting its authentication, response format, search capabilities, and rate limits. I also mapped the exact status fields and note formats the staff used.
4. IntakeQ audit: I reviewed the IntakeQ API to understand how to query form completion status and link it to a patient phone number.
5. Stakeholder interviews: I spoke with front-desk staff, the operations manager, and the owner. The owner wanted accuracy. The operations manager wanted visibility. Staff wanted less busywork.

The Insight That Changed Everything

During workflow shadowing, I discovered that roughly 25% of the staff’s time was spent on payments that were not “completed” — failed transactions, pending charges, or refunds that staff had to manually identify and filter out. Another 20% was spent on patients whose intake forms were incomplete, requiring staff to chase the patient by phone or email before the appointment. The client thought the problem was “we need faster staff.” The real problem was that the workflow forced humans to act as the glue between three systems that should have been connected automatically. This insight redirected the strategy from “hire more staff” to “remove the need for staff to do this at all.”

What I Built and Why

I chose n8n as the automation platform for specific reasons:

• Self-hosted on existing infrastructure: The client already paid for a VPS they were not using. Hosting n8n there meant no new subscription costs and full data control.
• API flexibility: n8n’s HTTP request node could handle DaySmart’s quirky SOAP-style API, Square’s REST API, and IntakeQ’s webhook format without needing native integrations.
• Multi-workflow architecture: I built one master workflow template and cloned it for each clinic, with environment variables for clinic-specific credentials and Slack channels.
• No staff retraining: The automation worked with the existing Square, IntakeQ, DaySmart, and Slack accounts. Staff only had to learn to read Slack alerts.

The Workflow Architecture

For each clinic, I built an n8n workflow with the following nodes:

Connecting Technical Decisions to Business Outcomes

Technical action: I configured Square webhooks to send payment events to n8n in real time, then wrote a Code node that parses the webhook payload and filters for status: "COMPLETED".

Business benefit: Staff no longer watch email inboxes for payment notifications. Failed and pending payments are filtered out automatically, so staff only see alerts for payments that actually matter.

Technical action: I built an IntakeQ lookup that searches by the phone number from the Square payment, queries the form completion status, and returns either “complete” or “incomplete.”

Business benefit: When the intake form is incomplete, the Slack alert says so immediately. Staff can call the patient right away instead of discovering the problem on the day of the appointment.

Technical action: I built a DaySmart update that searches for the patient by phone number, adds a structured note with payment details and intake status, and updates the appointment status to “ready” or “pending intake.”

Business benefit: Doctors can now open DaySmart and see, at a glance, which patients are fully prepared. No more surprises. No more wasted appointments.

Technical action: I designed a Slack message template that shows clinic name, patient name, payment amount, intake status, and a direct link to the DaySmart profile.

Business benefit: The operations manager can scan Slack and know the status of every payment and intake across all four clinics without asking anyone. Staff can triage incomplete intakes in seconds.

A real Slack alert showing the complete payment-to-intake summary — everything staff need in one place.

Built to Handle Edge Cases

I built the workflow to handle real-world complexity:

• If IntakeQ has no record for the phone number: The Slack alert shows “Intake not found” so staff know to follow up.
• If DaySmart has no matching patient: The alert shows “Patient not found in CRM” so staff can create the record or investigate.
• If the Square webhook sends a non-completed status: The workflow stops silently. No alert is sent. No staff time is wasted.
• If any API is down: The workflow logs the error and retries. If retry fails, the operations manager gets a direct Slack message so nothing is lost.

This meant the automation was safe to deploy. A failure in one clinic’s workflow would never affect another clinic, and no edge case would create a silent gap.

The Numbers

Business Impact

• 80% reduction in manual payment verification and intake processing time: The old workflow required staff to check email, open Square, verify status, open DaySmart, search for the patient, open IntakeQ, check the form, return to DaySmart, update the status, and add a note. The new workflow requires reading a Slack alert.
• Zero missed appointments due to incomplete intake or unverified payments: Since deployment, every payment is verified and every intake form is checked automatically before the patient arrives.
• Operations manager freed for higher-value work: The operations manager no longer spends his day checking what staff might have missed. He now focuses on opening new clinic locations and developing operational systems.
• Staff focus restored: Front-desk staff no longer context-switch between four applications for a single transaction. They handle Slack alerts as part of their normal workflow.
• No staff retraining or platform switching: The automation integrated with the existing Square, IntakeQ, DaySmart, and Slack accounts. Staff learned to read Slack alerts in under 10 minutes.

Technical Performance

• Real-time processing: Square webhooks trigger the workflow within 2–3 seconds of payment completion.
• ~3-second end-to-end latency: From Square webhook to Slack alert, the entire verification cycle completes in under 3 seconds for typical transactions.
• 100% uptime: The n8n instance (self-hosted on the client’s VPS) has run continuously since deployment with no manual intervention.
• Zero data loss: Error-handling nodes and retry logic ensure that no payment event is dropped, even if an API is temporarily unavailable.
• Four-clinic scalability: The master workflow template was cloned for each clinic with environment variables. Adding a fifth clinic requires copying the workflow and updating four variables.

What the Client Said

The operations manager reported that the biggest change was not the time saved, but the mental load lifted. Before, he had to wonder whether staff had caught every payment and every incomplete intake. Now he glances at Slack and knows the status of every transaction across all four clinics. The owner, who was initially hesitant about investing in automation for “something staff already do,” now asks what other workflows can be automated.

What Comes Next

The workflow is built to scale:

• New clinics: Adding a location requires copying the master workflow and updating clinic-specific credentials and Slack channel. The architecture handles the rest.
• Additional payment processors: If the client adds another payment provider, a new webhook trigger can feed into the same verification pipeline.
• Expanded CRM support: The DaySmart update node is modular. If the client switches CRMs, only that node needs updating.
• Analytics layer: n8n’s execution logs provide a complete audit trail of every payment processed, which could feed into a dashboard showing payment volume trends, intake completion rates, and clinic-by-clinic performance.

If your team is still manually verifying payments, checking intake forms, and updating CRM records by hand, you are losing hours every day to work that software should handle. The cost is not just time — it is missed appointments, frustrated doctors, and staff who could be doing higher-value work. I help clinic operators and service businesses find these hidden bottlenecks and replace them with quiet, reliable automation. If you are ready to stop letting manual verification drain your operations, book a workflow audit and I will show you exactly where your clinic is bleeding efficiency.