Stop-start demand
Activity that spiked and then fell away, with no lasting system underneath it.
How we built a lasting marketing system for a TMS practice — search and ads set up to keep bringing in good-fit consult enquiries month after month, rather than a burst of activity that stalls.
Case file 006 · 8 mo
The engagement
TMS
Treatment-resistant depression focus
Engine
A system that repeats
Search
Search content for each condition
Paid
Reaching people ready to book
Under NDA
Consult & treatment data private
Challenge
TMS interest had been chased in bursts — a campaign would run, bring in some interest, then go quiet. What the practice needed wasn't another push but a system: one that builds on itself and keeps producing good-fit consults predictably.
Activity that spiked and then fell away, with no lasting system underneath it.
Enquiries that didn't always fit TMS, wasting clinical consult time.
TMS still needs explaining before most patients will consider or search for it.
Little search foundation, so every result had to be paid for again rather than earned.
Approach
Mapping the path from depression-help interest to a good-fit TMS consult, with clear stages.
Condition and treatment content that earns search visibility that builds over time.
Targeted ads for people ready to act, with screening built into the booking path.
Tracking and tuning so the system keeps improving consult quality, not just numbers.
Results
Consult flow, enquiry quality, and channel performance were tracked in the practice's own platforms. Consult volumes and treatment-start figures are reconciled with the client and shared under NDA — not published here.
SYSTEM
Live
Repeatable demand engine shipped
CHANNELS
Search · Paid
Search that builds, plus ads that capture
OUTCOMES
Under NDA
Consult data from client analytics
An engine's worth is in real consults, and those numbers live in the client's systems — we reconcile and report them with permission, never inflate them.
Case files
Adjacent files
If you’re here, you’re probably comparing similar engagements. Here’s the surrounding work — services, problems we solved on the way, and the cities where this kind of programme runs.
Ready for your own case file?
We’ll show you the growth gap for your practice and the 90-day plan to close it.
More like this
Programmes like Options Psychiatry's usually combine local SEO, Google Search Ads and HIPAA-compliant tracking. The thinking behind them is on our mental health marketing page and in the mental health marketing guide.
The mental health marketing agency page sets out scope and pricing. Similar programmes include Harmony Neurocare and TWA Psychiatry, and the methodology explains how results are attributed.
Practical notes & supporting evidence
Client contextOptions Psychiatry · Mental
Marketing engineTMS
Public evidencePublished engagement scope
Read alongsideThe source period, programme scope and your own practice baseline
Options Psychiatry — TMS marketing engine is filed in the mental collection. The engagement record identifies marketing engine as TMS and channels as Search · Paid. Its published window is 8 mo. These details establish the scope available for public inspection. Read them alongside the client-specific material on this page when assessing whether the example relates to your own brief.
The page’s narrative and engagement record describe the work made public for Options Psychiatry. Use the named scope to identify which service questions to explore further. A channel listed in an engagement record describes programme coverage; evidence of a particular result requires the corresponding report and reporting period.
Mental-health marketing should explain the services offered, who provides them and how an initial enquiry is handled. Distinguish a general educational explanation from information about a particular treatment. Keep the contact route straightforward and make the destination of enquiries clear to the intake team. Language and accessibility choices should support understanding. Clinical suitability and patient-specific recommendations belong with the treating professional.
Start with the task a visitor needs to complete. Finding a treatment, checking a clinician’s background, identifying a location and asking for an appointment are related tasks, but they need different information. Make those paths visible in the navigation and on the relevant service pages. A good brief includes the content and the operational destination of each action: who receives the form, what happens after submission and how a visitor obtains help when the first contact route fails.
Desktop screens help explain page hierarchy, but they cannot establish the quality of the mobile experience. Check readable text, tap targets, menu behaviour and form validation on a phone. Long doctor biographies and treatment descriptions should remain easy to scan without hiding important details in decorative interactions. When a collection shows both desktop and mobile artwork, compare the priority of information across them. The mobile layout should preserve useful content rather than simply shrink the desktop composition.
A launch review should cover content ownership, approved contact information, working forms, redirects and the URLs that search engines are expected to index. If a site replaces an existing website, map important old pages to appropriate new destinations. Check titles, descriptions, canonicals and internal links against the actual released URLs. Keep the review list separate from the visual approval: a polished mockup does not prove that a live booking form, analytics event or redirect behaves correctly.
Document the difference between a design study, a delivered website and a live capture. A design study explains a proposed experience. A live capture records what the site looked like when it was captured. Neither alone establishes an improvement in appointment conversion. For an outcome comparison, use a defined period and consistent event definitions, then reconcile digital enquiries with attended appointments where the practice can do so. Performance and accessibility checks should be repeatable after future content edits, not only at the first launch.