How Website Support Requests
Work at Sland Studios
Support Service Level Agreement Overview
Purpose of This Support Service Level Agreement
This Support Service Level Agreement (SLA) outlines how website requests are handled at Sland Studios. It is designed to set clear expectations around response times, prioritization, billing, and warranty considerations before issues arise.
This document applies to all clients, whether you are on an ongoing support retainer or requesting support on an ad-hoc basis. It works alongside our Website Hosting, Ongoing Support Retainer, and MaestroPress License documents to explain how support fits into the broader way we maintain and care for your website over time.
Websites are dynamic systems. Software updates, server changes, third-party tools, and content edits by multiple team members all affect how a site behaves. This SLA exists to provide transparency around how support requests are assessed, what is included, and how time is allocated when work is required.
Our goal is not to make support feel rigid or transactional, but to ensure clarity, consistency, and fairness for both our clients and our team, and to support your business in a timely and efficient manner.
How Support Works at Sland Studios
All website support begins with a submitted Client Support Request through Sland Studios' support form. This ensures requests are properly documented, reviewed, and routed to the right members of our team.
When submitting a request, we establish urgency, if its a web server or website content request, along with all pertinent details.
Once a request is submitted, you will receive an automated confirmation acknowledging receipt, and then a real member of our team will follow up within the applicable response window to review the request and outline next steps.
Because websites are complex systems, not all requests can be fully understood or classified at the moment they are submitted. Some requests can be actioned quickly, while others require additional context or investigation before work can proceed.
Details, details, details!
The more clearly a request is described, the faster we can understand and action it. Providing clear context, screenshots, examples, and relevant details helps us avoid unnecessary back-and-forth and move work forward efficiently.
After reviewing a request, we will:
Provide a status update
Within response time window
Request additional info
Content, access, clarification, as needed
Quote and timeline
Estimated billable efforts and time to completion Where applicable
Confirm completion
Once the support request has been completed
This process allows us to handle support requests consistently, responsibly, and with transparency, while minimizing assumptions and delays, especially during emergency situations.
Note: In some cases, the time required to investigate a solution is equal to, or greater than, the time required to simply complete the work. In the interest of efficiency, Sland may proceed directly with the work rather than producing a formal quote.
Standard Rates
Effective February 1, 2026:
Standard Hourly Rate
Standard rate for all ad-hoc support requests during business hours
Emergency / After-Hours Rate
Applies to urgent, unplanned work outside standard response windows or business hours
Emergency rates are intended to cover situations where work must be reprioritized or handled outside of normal workflows. Ad-hoc requests are facilitated per this document.
Response Times
Upon submitting a support request, you will receive an automated acknowledgement confirming receipt. A member of the Sland Studios support team (a real human) will then follow up within the applicable response window outlined below, depending on the day and time the request is submitted. Actual resolution time will vary depending on the nature and complexity of the issue.
Weekdays: within 60 minutes
Monday – Friday
9am-4pm MST
*excluding stats & holidays
Weeknights: by 9pm MST
Monday-Thursday
Tickets received between 4pm-9pm
*requests received after 9pm will be reviewed 9am next business day
Weekends & Statutory Holidays: Within 12-24 hrs
Friday 4:00pm – Monday 9am
*Stats and holidays follow 'weekend' response time.
Response Time Guidelines
A real human employee at Sland will follow up on your support ticket within the response time outlined above. Once a request has been reviewed, we will follow up with next steps, which may include:
- Requesting additional information
- Providing a quote and estimated timeline
- Confirming that the issue has been resolved
Statutory Holidays & Reduced Availability
Support tickets that are submitted during a stat holiday will receive weekend response times turnaround.
2026 Alberta Statutory / Common Observed Holidays
- New Year's Day: January 1
- Family Day: February 16
- Good Friday: April 3
- Victoria Day: May 18
- Canada Day: July 1
- Heritage Day: August 3
- Labour Day: September 7
- National Day for Truth and Reconciliation: September 30
- Thanksgiving: October 12
- Remembrance Day: November 11
- Christmas Day: December 25
- Boxing Day: December 28 (Observed)
(Holiday coverage and availability may vary year to year.)
Important: What's Not Included in Response Times
Response covers an initial review and acknowledgment, not completion of work. Due to the variable nature of requests, actual resolution time depends on many factors.
Core Support Rules: Billing, Non-Billable, & Warranty
Website support involves investigation, context, and technical judgment. For that reason, the following core rules apply to all support requests, whether submitted by retainer or non-retainer clients.
Billable Support
Support requests are billable by default.
This includes time spent:
- Reviewing and understanding the request
- Investigating the cause of an issue
- Consulting internally with the team
- Consultation or meetings with the client to gather additional information
- Testing, fixing, or validating solutions
As you can see, even small support requests potentially require many team members, communication, and management. For retainer clients, this time is applied against available retainer hours. For non-retainer clients, work is billed at the applicable hourly or emergency rate.
Non-Billable Support
Support may be considered non-billable in limited cases, such as:
- A straightforward quote request* that does not require investigation
- A quick clarification that can be answered without hands-on review, testing, or internal consultation
*Note that this does not include quotes for complex features that require planning, requirements gathering, or extensive communication with third parties.
Warranty Support
Warranty support applies only to recently delivered work and is limited in scope.
In general:
- Features, updates, or custom code delivered within the last six (6) months may qualify for warranty review
- Work delivered prior to that period is considered completed scope, and revisiting or updating this work is considered new scope.
Warranty does not apply to issues caused by:
- Software or server updates
- Third-party plugins, services, or integrations
- Client-made content or configuration changes
- Normal website maintenance or evolving platform requirements
If there is uncertainty around whether an issue qualifies as warranty work, we will review the situation and communicate our assessment before proceeding.
Why These Rules Exist
Websites are dynamic systems. Software versions change, dependencies evolve, and multiple parties interact with the site over time. These rules ensure support is handled consistently, fairly, and sustainably, while keeping expectations clear for everyone involved.
Best Practices for Submitting Support Requests
Clear, well-described support requests help us understand issues faster and resolve them more efficiently. While we're always happy to help, following the best practices below can significantly reduce back-and-forth, turnaround time, and total billable hours.
Helpful Tips
When submitting a support request, please:
Be Specific
Be as specific as possible about the issue or request. Include links, page URLs, or examples where the issue is occurring.
Provide Context
Let us know when the issue started or what changed recently, if applicable. Context helps more than urgency.
Include Evidence
Attach screenshots or screen recordings if something looks incorrect or broken.
Test First
Clear your browser cache (hard refresh), try incognito mode, or test on different devices/networks.
Timing & Urgency
Indicate whether the issue is time-sensitive or related to an upcoming launch or deadline.
Reference your Manual
Consult your website training manual to see if the issue (and its solution) is covered by those materials.
One Request = One Ticket
Whenever possible, submit separate support requests for unrelated issues. This helps us:
- Triage correctly
- Prioritize accurately
- Avoid confusion or missed details
Context Helps More Than Urgency
Marking a request as urgent is helpful when appropriate, but providing context (what you expected vs what you're seeing) is often more valuable than urgency alone.
If You're Unsure
If you're not sure how to classify a request, submit it anyway with as much detail as you can. We'll review it and follow up with questions or next steps as needed.
Common Scenarios & Examples
The scenarios below are intended to illustrate how support requests are typically handled in real-world situations. While every request is reviewed individually, these examples help clarify how billing, warranty, and response expectations are generally applied.
Website is slow, showing an error, or displaying a blank page
Sland will confirm if it is a website hosting issue (is the server causing the issue), or a website application issue (did something on the website break). Sland will attempt to identify the cause of the issue, which may include checking recent updates, plugins, themes, server logs, or third-party integrations.
- If the issue is caused by required maintenance, software updates, or server-level changes, this is considered billable support
- If the issue is directly tied to a recently delivered feature or update that is not functioning as intended, it may be reviewed under warranty, where applicable
Emergency issues outside standard business hours
Emergency issues affecting availability or security are reviewed as soon as possible, based on the response times outlined in this SLA.
Emergency work may involve after-hours response and applicable emergency rates. We will communicate clearly before proceeding whenever possible.
This is where it is important to submit a support ticket with clear expectations on turnaround time and labeling the urgency appropriately to avoid emergency rate billing.
This was working yesterday, but now appears changed/broken
If a new feature, content update, or webpage is not working as it was previously, Sland will have to investigate and will by default track billable time to do so.
Common causes:
- Unstable update or bug in code Sland wrote (non billable)
- Conflicting update; some client updates or plugins added may conflict with other plugins or code causing issues (billable)
- Server or third-party software upgrade causing existing site functions to break (billable)
Frequently Asked Questions
How are non-billable support requests handled?
Support requests are billable by default, unless they are limited to a straightforward quote request or clarification.
If a request can be answered quickly without investigation, internal consultation, or hands-on review, it may be considered non-billable. However, if determining the answer requires investigation or review, that time is considered billable.
How is warranty support handled?
Warranty support applies only in limited circumstances and for a defined period following delivery.
If a recently implemented feature, update, or custom code is clearly not functioning as intended or was not completed to the agreed specification, it may be reviewed as warranty work.
As a general guideline:
- Features or functionality launched within the last six (6) months may qualify for warranty review
- Anything older is considered completed scope
Warranty does not apply to issues caused by software updates, server changes, third-party tools, or client-made edits.
What is involved in investigating a support request?
Investigating a support request often involves more than reviewing what is visible on the site. Time is frequently required to understand context, confirm the cause, and determine the most responsible next step.
In general:
- If a straightforward request can be quoted with minimal internal discussion, that quoting effort is non-billable
- If a request requires meaningful investigation to understand scope, risk, or impact, that effort may be billable. We will notify you in advance where possible
Investigation and implementation may include:
- Reviewing the request and related correspondence
- Internal team discussion or consultation
- Technical investigation or testing
- Project management and coordination
- Development work
- Quality assurance (QA)
- Follow-up communication
These steps are required for both small and large requests. Ongoing support retainers provide added flexibility for this type of investigative work and allow us to move more efficiently.
Why did Sland bill me when I asked them to look into something, and they just completed the request instead?
In some cases, the time required to investigate a request is equal to, or greater than, the time required to complete it. To avoid unnecessary back-and-forth, delays, or additional cost, we may proceed directly with the fix once the issue and solution are clear. This approach is taken in the interest of efficiency and is consistent with how website support is handled under our Support Service Level Agreement.
How are PCI-related updates and compliance maintenance handled?
Websites that process payments require ongoing plugin and platform updates to remain PCI compliant.
- For retainer clients, required PCI-related updates are handled as part of ongoing support
- For non-retainer clients, PCI-related updates are not included and must be explicitly requested as billable support
PCI compliance is an ongoing responsibility, not a one-time setup.
Access our Ongoing Support Retainer service page for more details.
I have several support requests, what is the best way forward?
When multiple unrelated updates are submitted together, they may be separated or scheduled to ensure clarity and proper handling.
- Retainer clients can often bundle related work efficiently
- Non-retainer requests are typically scoped and approved individually
Submitting unrelated requests as separate tickets helps avoid delays and confusion.
Large Ongoing Scope in the Works?
Our operations team may reach out to coordinate on tracking changes outside of support form for efficiency.
*If you have regular website update support requests, consider an Ongoing Support Retainer to receive regular strategic meetings and a discount rate to complete new work
How should campaigns, events, or high-traffic periods be handled?
Planned launches, campaigns, or events benefit greatly from advance notice.
Providing context ahead of time allows Sland to:
- Anticipate traffic or performance needs
- Schedule updates appropriately
- Reduce the risk of last-minute or emergency requests
Quarterly check-ins included with retainers are particularly helpful for planning around these moments.
What happens if I don't have an ongoing support retainer?
Clients without a retainer are still fully supported.
However:
- Requests are handled reactively, as they come in
- Work typically requires scoping and approval before proceeding
- Requests are subject to availability and standard or emergency rates
- Due to lack of regular check-ins and context, billable investigation and resolution time may be longer than for retainer clients
Retainers allow for greater flexibility, continuity, and efficiency, but they are not required.
Access our Ongoing Support Retainer service page for more details.
What happens if we need to upgrade or replace our WordPress Website Builder?
A "page builder" is a WordPress plugin that controls how pages are built and edited (layout tools, content blocks, templates, and styling). Examples include WPBakery, Elementor, and Bricks.
Over time, it may become necessary to upgrade or replace a builder due to the dynamic nature of websites and plugins, such as:
- Long-term compatibility issues with newer versions of WordPress, PHP, or other required plugins
- Performance or accessibility limitations that become harder to work around
- Vendor changes (reduced support, licensing shifts, security concerns, or product direction)
- A newer builder becoming a better fit for long-term stability, speed, and maintainability
Important: Changing builders is not an "automatic update." It's a structural change to how your website pages are built, and it typically requires planning, testing, and page-by-page review or rebuild work. For that reason, builder migrations are not included in hosting, warranty, or baseline maintenance and are handled as billable website work.
This is similar to how other major platform shifts happen over time: the underlying tools that power a website evolve, and sometimes the responsible path forward is a planned migration rather than patching an older system indefinitely.
Where possible, we'll:
- Flag risks early (ideally before something breaks)
- Recommend options with rationale
- Provide an estimated scope and approach before moving ahead
Why might a feature that worked previously need to be rebuilt?
Websites are dynamic systems. Over time, changes to WordPress, plugins, server software, or third-party services can make an existing feature unstable, inefficient, or incompatible, even if it previously worked as expected.
In these cases, continuing to patch the original implementation is often not the best long-term solution. Instead, we may recommend rebuilding the feature using a more current, compatible, or supported approach.
A rebuild may be recommended when:
- Platform or software updates introduce compatibility issues
- Performance or stability degrades over time
- Older custom code no longer aligns with best practices
- Security, accessibility, or maintainability concerns arise
Rebuilding a feature is considered billable maintenance or enhancement work, not warranty, once it falls outside the original delivery window or is affected by broader platform changes.
When this happens, we'll explain why a rebuild is recommended, outline the options, and confirm scope before proceeding. This approach helps ensure your website remains stable, secure, and maintainable over the long term.
Why do issues sometimes appear "out of nowhere"?
Websites are dynamic systems. Software updates, server changes, third-party tools, and content edits by multiple users can affect how a site behaves over time.
An issue may surface even if no recent changes appear obvious. Investigation is often required to determine the cause and appropriate fix.
Why doesn't hosting cover fixing website issues?
Hosting covers the infrastructure your website runs on, including uptime, monitoring, and backups.
Website issues related to WordPress, plugins, themes, or custom code fall under website support, which is governed by this SLA and handled through ad-hoc support or a retainer.
Access our Hosting service page for more details.
Does Sland manage Email?
No. Email falls within the purview of your IT provider, and due to the sensitive and business-critical nature, Sland does not manage email nor DNS settings to configure email.
Can I change or cancel my retainer later?
Ongoing support retainers are typically committed to for a one-year term.
Within that term:
- Plans may be adjusted up or down as needs change, subject to review
- Renewals are revisited at the end of the term
This structure provides stability while allowing flexibility as your needs evolve.
Access our Ongoing Support Retainer service page for more details.