Everything you need to manage your account, hosting and support

This handbook is designed to be the practical operating guide for working with SKUNKWORK™ and SKUNKHOST™.

A Covered Website means one WordPress installation with its primary domain and content stack.

• One maintenance plan covers one Covered Website unless agreed otherwise in writing.
• One hosting service supports one managed WordPress build unless agreed otherwise in writing.
• Extra websites, extra WordPress installs, or separate projects normally need extra cover or a quote.

Customer-facing names are SKUNKWORK Care™, SKUNKWORK Grow™, SKUNKWORK Tech Team™, SKUNKHOST Core™ and SKUNKHOST Pro™.

Some portal URLs may still contain older route aliases. That is normal and does not change the public plan name.

The Client Portal is your account and service control centre.

• Use the dashboard for a fast account snapshot, not for deep service configuration.
• Billing widgets help you spot unpaid or upcoming invoices.
• Support widgets help you see open ticket activity.
• Service areas help you jump into hosting, maintenance or product details.

• Use quotes when reviewing proposed work or a commercial change.
• Use the order confirmation and service record when checking what is actually live on your account.
• If there is a conflict between public wording and your purchased spec, the order-time portal product spec prevails.

• Reply to the existing ticket instead of opening a duplicate thread for the same issue.
• Answer all open questions in one reply where possible.
• Attach updated files or screenshots to the same ticket.
• Use one clear approval message when sign-off is needed.

• Look for replies from the team inside the ticket thread.
• Check whether further information, access or approval is required.
• If the ticket is waiting on you, reply there so the team can move it forward.
• Completion notes should remain attached to the ticket for future reference.

• Keep the account email monitored by someone responsible.
• Update billing contact details when your finance setup changes.
• Make sure the right people are invited to the account instead of forwarding every message manually.

The safest commercial reading starts with what was accepted and what is attached to the purchased service.

• Accepted quotes govern the scope they cover.
• The invoice, order confirmation and portal product specification govern the purchased product at the time of order.
• The Terms and Scope pages then govern the wider legal and operational position.

Promotional pricing should always be read against the live offer details and your own service record.

• Apply discount codes exactly as shown at checkout if the offer is still live.
• Promotions are usually subject to eligibility and timing rules.
• If a subscription is paused, promotional pricing may not carry forward unless expressly agreed.

• Watch for renewal invoices in the Client Portal.
• Pay on time so the account stays in good standing.
• If something on the renewal looks wrong, raise it before the due date.

• Use a quote when the request is outside standard scope.
• Use a quote when you need multi-site, unusual commercial structure or non-standard terms.
• Use standard portal routes whenever an ordinary product already covers the need.

Move through a standard portal path when the route exists. Use a quote or ticket when the change is non-standard.

• Upgrade when you need more kit access, faster delivery windows or more hosting resource.
• Downgrade only after checking what you will lose in the move.
• Do not assume every change is instant if provisioning or account checks are still required.

• Download invoices from the portal for bookkeeping and finance review.
• Keep account contacts current so finance notices reach the right person.
• If your accountant needs a clean record, use the invoice history inside the portal first.

Tickets are the formal operating record for support and task delivery.

• They show what was requested.
• They hold attachments, approvals and clarifications.
• They make the job auditable from start to finish.

• Clear brief
• Named website or service
• Required access where needed
• Relevant files, screenshots or examples
• Any needed approvals or confirmations

An on-hold ticket is not being ignored. It usually means the task cannot progress cleanly yet.

• Reply promptly with what has been requested.
• Keep all follow-up inside the same ticket.
• If a third party is involved, mention that clearly so expectations stay realistic.

• Use one ticket for one main issue or change.
• Open a new ticket when the next job is unrelated.
• If you bundle unrelated items together, you may be asked to split them.

• Total site outage
• Severe live security incident
• Ransomware or active malware causing harm
• Live checkout failure on a trading store
• Immediate business interruption risk

A completed task is normally one that meets the brief and acceptance criteria attached to that ticket.

• New direction after completion is a new request.
• Later amendments may become a follow-on task.
• Keep the completion notes for future reference.

• Provide the right access
• Answer questions clearly
• Approve when approval is needed
• Supply assets, text or files on time
• Avoid changing the brief mid-task unless you want a re-scope

The most suitable environment may be staging, development or production depending on the task.

• Some urgent fixes and DNS changes may need production work.
• Some changes may wait for your approval before deployment.
• Third-party dependencies can still affect launch timing.

Plesk is where you manage hosting operations rather than account billing.

• Use the dashboard for a quick health and access overview.
• Domain/subscription panels show the site spaces under your control.
• Tool shortcuts help you move into files, databases, mail and WordPress management.

• Use subdomains when you need a separate hostname under the same main domain.
• Set the document root and SSL requirements correctly.
• Make sure DNS exists for the subdomain if required.

• Confirm which database belongs to which site before making changes.
• Keep credentials secure and use least-privilege where possible.
• Take exports or backups before destructive work.

• Review the current PHP version and key directives before changing anything.
• Use the supported configuration path shown in Plesk.
• After changing a PHP version or setting, test the website and admin area immediately.

Only use the Plesk DNS editor when the live DNS for that domain is actually controlled there.

• Check that the domain resolves correctly before issuing SSL.
• Confirm the certificate is attached to the right domain or subdomain.
• Renewal and automation can still fail if DNS or validation is incorrect.

Backups are important, but do not treat them as magic or infallible.

• Know where backups are configured and how often they run.
• Take a fresh backup before major changes where possible.
• Keep your own independent copy for critical business continuity.

• Open the correct domain before reading logs.
• Check timestamps carefully.
• Use logs to confirm patterns before changing configuration.

• Use redirects for clean destination changes.
• Use aliases only when you understand how they interact with hosting and SSL.
• Test both HTTP and HTTPS outcomes after changes.

• Create only the jobs you genuinely need.
• Set frequency carefully so the server is not overloaded.
• Log outputs where possible so failures can be traced.

Developer tools may be available in your hosting environment, but they should be used carefully on live production sites.

• Confirm the tool is present and supported in your subscription.
• Use documented deployment or update steps rather than experimenting on a live site.
• Keep technical changes coordinated with the ticket record if SKUNKWORK is also involved.

• Your service and role decide what you can access.
• Some options may be hidden, limited or withdrawn for security or stability reasons.
• If you expected a feature that is not visible, check the purchased service and permissions first.

DNS is the traffic map for your domain.

• Some users may see the new answer before others do.
• Old cached records can persist until TTL expiry and resolver refresh.
• Do not panic if the change appears inconsistent for a while after update.

• Use CNAME when a provider gives you a target hostname rather than an IP.
• CNAME is common for verification, tracking and service-specific hostnames.
• Do not place a CNAME at a hostname that already needs incompatible record types.

Website DNS and email DNS are related but not identical. Your website can point one way while MX handles mail elsewhere.

• Use the correct priority values supplied for your mail platform.
• Remove obsolete MX entries if they are no longer needed.
• Pair MX with SPF, DKIM and DMARC for better deliverability.

• Lower TTL can help planned changes spread more quickly.
• Higher TTL can reduce query churn for stable records.
• TTL is only one part of propagation; resolver behaviour still matters.

• The domain must resolve correctly.
• Validation checks must reach the right endpoint.
• Recent DNS changes can delay or break certificate issuance until propagation settles.

This is a common setup. The website can point to SKUNKHOST™ while mail continues through another provider.

• Website records must point to the hosting destination.
• MX and related email authentication records must continue to point to the chosen mail platform.
• Check every existing mail-related record before switching nameservers.

• Confirm the correct record exists in the authoritative zone.
• Allow time for propagation.
• Test the actual service affected: website, mail, or verification.

• Changing records in a non-authoritative DNS panel
• Replacing MX values without understanding the current mail platform
• Using the wrong hostname or leaving out a required record
• Forgetting that propagation takes time
• Making several unrelated changes at once and losing track

SKUNKHOST™ is the hosting side of the platform. It is built around managed WordPress rather than generic unmanaged hosting.

• One hosting service is not a silent multi-site entitlement.
• Additional websites usually require additional hosting services or a separate agreement.
• The same baseline applies to plans that include hosting unless agreed otherwise.

• Site-space creation
• Server-level and site-level security controls
• SSL issuance where included
• Mailbox provisioning where included
• Backup configuration where included
• A standard performance stack appropriate to the platform

Backups are part of responsible hosting, but they should be treated as a layer of protection rather than a guarantee of perfect recovery.

• Use hosting backups as an operational safeguard.
• Take your own independent backups before major work where possible.
• Test critical recovery paths if your business depends on them.

• Ongoing redesign work
• Open-ended development retainers
• Unlimited custom feature creation
• Multi-site entitlement under one standard hosting service
• Automatic email migration or deep remediation work

• SPF, DKIM and DMARC should be configured correctly.
• Mail routing should be clear and not conflicted between providers.
• Deliverability can never be absolutely guaranteed across all receiving platforms.

• Correct live DNS is essential.
• Domain validation must succeed.
• Automation can still fail because of rate limits or third-party certificate authority issues.

Unlimited language should be read as fair-use within the platform model, not as an invitation to ignore normal hosting boundaries.

• One managed WordPress build remains the baseline.
• Abusive or structurally unsuitable use may require a change of product or a quote.
• The service is managed for operational stability, not positioned as an unrestricted raw server.

• Good for single smaller websites with modest mail needs
• Good when you want managed WordPress hosting at the entry tier
• Good when you do not yet need the bigger mailbox count or wider headroom of Pro™

• Better for larger or busier sites
• Better where mailbox demand is higher
• Better where you want more headroom and premium extras from the start

Maintenance is the managed delivery layer for ongoing WordPress site work.

• Standard plans are generally consecutive by default.
• Tech Team™ may run multiple concurrent tasks.
• Even where concurrency exists, active parallel work can still be capped.

• It does not mean unlimited scope.
• It does not mean unlimited multi-site coverage.
• It does not mean automatic access to kits outside your plan.
• It still depends on readiness, queueing, working hours and feasibility.

Maintenance can be taken on its own or through a combined route where that option is currently offered.

• Check the live plan route or service record for the exact hosting combination attached.
• If you start with maintenance only, hosting may be added later where the offer still applies.

• Tickets should identify the website clearly.
• Requests for other websites sit outside the normal one-plan baseline.
• Extra websites usually need extra cover or a separate commercial arrangement.

• Website fixes and issue resolution
• Content updates and page management
• Design tweaks and visual assets

• Performance optimisation
• WooCommerce catalogue work
• SEO, forms, plugins, compliance and analytics
• Faster and broader operational support than Care™

• Advanced WooCommerce work
• CRO
• Campaign support
• Email and CRM integration
• AI and smart features
• Custom development and edge-case tasks

• Structured
• WordPress-first
• Delivered through predefined kits
• Focused on maintenance, support, security and incremental improvement

• Not a generic non-WordPress engineering retainer
• Not an automatic full website rebuild programme
• Not a promise to build standalone SaaS products
• Not open-ended server engineering beyond hosting agreement scope

• Stable, live websites are the best fit for structured ongoing support.
• Mid-build, structurally incomplete or unresolved third-party projects may be declined or delayed.
• Where the platform is unstable before onboarding, the first step may be recovery or a separate commercial arrangement.

• Split large programmes into clear work units.
• Use quotes for non-standard commercial or technical structures.
• Expect some requests to be reclassified into a different kit or arrangement.

• Separate websites usually need separate service cover.
• Separate projects on the same site can still need separate tickets.
• Large new directions can become new commercial work rather than being absorbed automatically.

Fix faults, conflicts, breakages and core stability problems inside WordPress.

Common examples

• Break/fix incidents
• Plugin or theme conflicts
• CSS layout breakages
• Update recovery

Usually outside baseline scope

• Non-WordPress platforms
• Server engineering beyond hosting scope
• Full rebuilds from scratch

Handle day-to-day copy, page, media, menu and on-page content changes.

Common examples

• Text edits and page rewrites
• Image swaps and gallery updates
• Blog uploads and formatting
• New pages built with existing site components

Usually outside baseline scope

• Legal drafting
• Multi-site content strategy as one task
• Full information architecture rebuilds

Deliver design polish, graphics and tightly defined creative outputs.

Common examples

• Website graphics and banners
• Section visuals and visual polish
• Static social creatives
• Print-ready artwork

Usually outside baseline scope

• Video or motion production
• 3D modelling
• Unlimited revision loops

Improve front-end speed, page weight and user-perceived performance inside WordPress constraints.

Common examples

• Caching and performance plugins
• Image optimisation
• Font and asset tuning
• Builder clean-up where feasible

Usually outside baseline scope

• Raw server engineering
• Guaranteed benchmark scores everywhere
• Front-end rewrites into bespoke frameworks

Manage products, categories, variations and standard catalogue operations inside WooCommerce.

Common examples

• Product creation and edits
• Categories, tags, attributes and SKUs
• Bulk CSV updates where supported
• Basic merchandising and product SEO hygiene

Usually outside baseline scope

• Enterprise inventory architecture
• Non-WordPress ecommerce
• Multi-warehouse engineering

Handle gateways, shipping, tax, checkout behaviour and standard order-flow tuning.

Common examples

• Payment gateway configuration
• Shipping and tax rules
• Checkout troubleshooting
• Order email and status flow adjustments

Usually outside baseline scope

• Custom payment processor engineering
• Enterprise billing platforms
• Highly bespoke checkout logic without reclassification

Improve on-site SEO hygiene and resolve common WordPress SEO issues.

Common examples

• Metadata and schema setup
• Indexing fixes
• Internal linking improvements
• SEO plugin configuration

Usually outside baseline scope

• Guaranteed rankings
• Backlink campaigns
• Paid ads management

Refine layouts, messaging and journeys to reduce friction and improve conversion behaviour.

Common examples

• CTA placement improvements
• Form simplification
• Trust and clarity blocks
• Supported A/B or heatmap setup

Usually outside baseline scope

• Guaranteed revenue uplift
• Enterprise experimentation platforms
• Full marketing strategy documents

Build and improve lead forms, notifications, routing and supported integrations.

Common examples

• Contact, quote and enquiry forms
• Autoresponders and notifications
• Spam protection
• Conditional logic and basic routing

Usually outside baseline scope

• Custom standalone form software
• Enterprise lead distribution architecture

Install, configure and activate plugin-driven features inside WordPress.

Common examples

• Plugin configuration
• Feature enablement
• Membership or booking setups where supported
• Basic user guidance

Usually outside baseline scope

• Building entirely new software
• Defaulting to custom plugin development for ordinary needs
• Non-WordPress feature work

Implement privacy and compliance tooling as configuration work, not legal advice.

Common examples

• Cookie banners
• Consent tools
• Policy link placement
• Consent-aware script controls

Usually outside baseline scope

• Drafting legal documents
• Formal legal advice
• Compliance certification

Configure mainstream analytics, tracking and conversion measurement tools.

Common examples

• GA4 and GTM
• Meta Pixel
• Search Console
• Merchant Center standard setup

Usually outside baseline scope

• Enterprise data science analysis
• Custom analytics engineering
• Running paid ad budgets

Build and support campaign pages, promo sections and launch assets inside WordPress.

Common examples

• Landing pages
• Promo sections and announcements
• Campaign pixel implementation
• UTM hygiene and post-launch tweaks

Usually outside baseline scope

• Full marketing strategy
• Paid media management retainers
• Ad-spend optimisation

Connect WordPress to CRM and email tools using supported workflows and integrations.

Common examples

• Form-to-CRM routing
• Automation flows
• Segmentation and tagging
• Webhook-style supported connections

Usually outside baseline scope

• Custom CRM platforms
• Enterprise sales architecture
• Deliverability guarantees

Deploy AI-driven features using WordPress-compatible tools and integrations.

Common examples

• AI plugins
• Chatbots
• Prompt and flow setup
• Lead capture routing into forms or CRM

Usually outside baseline scope

• Training proprietary AI models
• Building AI SaaS products
• Non-WordPress AI app engineering

Handle advanced WordPress-native customisations and tricky edge-case integrations.

Common examples

• Hooks and filters
• Custom functions
• API integrations
• Advanced WooCommerce customisation

Usually outside baseline scope

• Standalone software products
• Non-WordPress applications
• Multi-year product engineering

• Use the Client Portal / ticketing system where instructed.
• Use secure credential tools chosen by the company where provided.
• Do not send plain-text passwords or sensitive tokens over unapproved channels.

• Create role-appropriate access rather than sharing a super-admin credential by default.
• Use temporary accounts where possible.
• Remove old users and stale credentials after completion.

• Use MFA where the platform supports it.
• Rotate credentials that were created purely for a short-term job.
• Store recovery details securely and not in plain text.

• Open a ticket immediately if the issue affects a live site, login integrity, malware risk or payment flow.
• Describe the impact, not just the symptoms.
• Do not change ten things at once before reporting or you may destroy useful evidence.

• Keep software updated appropriately.
• Use strong passwords and least privilege.
• Treat backups as part of resilience, not the entire security model.

• Public pages are good for current guidance and comparison.
• Service records govern what you actually bought.
• Where a conflict exists, the order-time portal product specification prevails.

• Registries, payment processors, certificate authorities and external vendors can all introduce delay.
• Third-party bugs, approvals or outages can affect outcomes.
• Best-efforts service still cannot override external systems.

Best-efforts is not a shrug. It means the work is pursued responsibly while recognising that some systems or outcomes cannot be fully controlled.

• Migrations can still meet hidden legacy problems.
• Backups can still fail in some technical scenarios.
• SSL automation can still fail if DNS or validation conditions are wrong.

• Not every client will see every function.
• Risk management can justify reduced or withdrawn control-panel access.
• This is an operational safeguard, not automatically a service fault.