Managing Multiple jekcms Clients: An Agency Playbook

Running jekcms for multiple clients is less about any single tool and more about having repeatable processes (for deployment, updates, licensing, and support) that don't depend on one person remembering all the steps.

A Deployment Checklist That Actually Gets Used

A written checklist you run through before every client handoff catches more problems than any single tool. Cover environment configuration, database setup, SMTP delivery verification, cache warm-up, a walkthrough of every admin section the client will actually use, and a basic security review. The value isn't in any particular item: it's having a repeatable list so nothing gets skipped when you're moving fast between projects.

Keeping Client Customizations Separate From Core

The cleanest way to avoid update trouble is to keep site-specific changes out of the core files. A jekcms update copies the files in the package over the ones on the server, so anything you edit in the core or in a bundled theme is lost at the next update. An update does not touch a plugin folder with its own name that is not in the package. If a client needs custom functionality (an extra panel screen, a separate page on the site, an integration), write it as a small plugin under plugins/. If the theme needs changes, copy the bundled theme and create your own under a new name.

Licensing for Multiple Sites

jekcms plans are split by site count: 1, 3, 10 or unlimited sites. A license is tied to the domain it is activated on. From the customer panel you can remove a domain and add a new one, or move to a higher plan, without opening a support ticket. When work with a client ends, freeing that seat for the next project takes a few minutes.

Support Escalation That Doesn't Depend on One Person

A structure that works for most agencies: clients go through a single point of contact rather than emailing whoever they last spoke to, and that contact triages within a defined, communicated window: same-day is a reasonable target for most agencies. Bugs in jekcms core get routed to jekcms support; client-specific issues (theme tweaks, content questions, admin usage) stay internal. Avoid giving clients direct SSH or database access; route changes through the CMS or a documented process with a clear rollback step, so a mistake is recoverable.

Keeping Multiple Sites Updated

jekcms's update channel is signed and hash-verified, and core, theme, and plugin updates apply with one click from the admin panel: there's no need to hand-patch files across a portfolio of sites. For an agency managing several installations, the practical discipline is less about tooling and more about cadence: decide how quickly you roll a new release out across client sites (immediately for security fixes, on a slower reviewed schedule for feature releases), and always let the built-in backup step run before applying an update rather than skipping it to save time.

Tracking Cost and Pricing Client Work

Whatever your actual numbers are, it's worth tracking hosting cost, your own time spent on maintenance and support, and license fees separately per client: bundling them into one vague "monthly retainer" number makes it hard to tell later whether a specific client relationship is actually profitable. A simple license lifecycle is enough to keep this manageable: provision the key during onboarding, activate it against the live domain, set your own renewal reminder cadence before it expires, and deactivate it promptly when a client leaves so the seat isn't sitting idle.

Client Onboarding Practices Worth Adopting

• Record a short screen walkthrough of the admin panel using the client's actual content: generic documentation tends to get ignored.
• Create a sandbox admin account the client can experiment in without touching the live site.
• Establish a single point of contact on the client side: multiple contacts tend to produce conflicting change requests.
• Set response-time expectations in writing before the project starts, not after the first support ticket.
• Keep a running note of client-specific customizations somewhere your whole team can find it, not just in one person's memory.
• Schedule a check-in a few weeks after handoff to address questions that only come up once the client has used the system on their own.

A shared internal reference (one page per client, noting the theme in use, any custom plugin behavior, the SMTP provider, and known quirks) tends to pay for itself quickly once support volume picks up: whoever picks up a ticket can get context without digging through configuration files or asking around.