This policy sets out the availability commitment, service credits and support response targets for paid SIMCOAI plans. It forms part of your agreement with SIMCOAI LTD under the Terms of Service.
This document forms part of your agreement with SIMCOAI LTD. It is not legal advice for your own business; take independent advice for regulated, sensitive or high-volume use cases.
No matching sections found.
Standard support covers account access, billing guidance, configuration questions, docs, known incidents, reasonable troubleshooting and product defects.
It does not include legal advice, tax advice, telecoms consulting, custom development or third-party account administration unless agreed.
Live operational status, active incidents, recent incident history and known issues are published at uptime.simcoai.co.uk. It is the first place a platform incident appears and is the fastest way to establish whether a problem is on our side.
SIMCOAI depends on third-party providers for telephony, payments, AI models and network delivery. The service is designed to degrade gracefully and to fall back where a provider fails, but no provider — including ours — can promise uninterrupted availability, and we do not publish an uptime percentage we would not be able to stand behind.
Edge protection is in place and is designed to help absorb malicious traffic and filter abusive requests. It reduces exposure; it does not make the service immune to attack, and we will not claim otherwise.
Where a problem is not shown on the status page, please report it with the time, what you expected, what happened, and any request identifier. This is described in our documentation under contacting support.
For paid plans, SIMCOAI targets Monthly Uptime of at least 99.5% for the core dashboard, AI chat and API. Monthly Uptime is measured per calendar month as the percentage of minutes the core service is available, excluding planned maintenance notified in advance, emergency security maintenance, and the exclusions below.
If Monthly Uptime for a paid plan falls below the target, you may claim a service credit against a future invoice: 99.0%–99.49% earns a credit of 5% of that month’s subscription fee; 95.0%–98.99% earns 10%; below 95.0% earns 25%. Credits must be claimed within 30 days of the end of the affected month by emailing [email protected] with the dates and times observed. Credits are capped at 25% of the affected month’s fee, are not redeemable for cash, and are your sole and exclusive remedy for availability failures. Trials and free accounts are excluded.
Availability is measured by automated monitoring of the core service from outside our own infrastructure, checking at regular intervals throughout each month. A check counts as a failure if the core service does not respond correctly within a reasonable timeout. Monthly Uptime is a statistical measure over the month as a whole, not a guarantee that no individual request was ever affected.
You can reach us by phone on +44 7576 569444, through the support routes in your dashboard, using the public contact form, or by email at [email protected]. For account-specific help, contact us from the business account email where possible.
The support line is answered by a digital assistant that can answer common questions immediately, and you can ask for a person at any point — press 2 or say so. If nobody is available it takes a callback rather than leaving you holding. Calls to it are answered by SIMCOAI itself and are covered by the recording and AI disclosure read out at the start of the call; the line is open during UK business hours and messages left outside them are picked up the next working day.
Include request IDs, timestamps, affected page/number, screenshots without secrets, and safe reproduction steps.
During incidents SIMCOAI may investigate, rate-limit, disable risky features, reroute, fall back, post status guidance or ask customers to pause a workflow.
Enterprise customers may have additional notification or review terms in their contract.
We take encrypted local recovery copies hourly. They can help recover from accidental changes, but they are on the same hosting server and do not provide separate-site disaster recovery. Restoring a copy may require downtime and may not include changes made after its recovery point.
Live and historical service status is published at uptime.simcoai.co.uk, including current incidents, past incidents and their resolution, and the status of each major SIMCOAI capability. You can subscribe there to be emailed when a public incident opens and when it is resolved.
For a Severity 1 incident affecting the core service, once it is resolved we will post a plain-English summary on the status page describing what happened, who was affected, and what changed as a result, within a reasonable time afterwards. This does not extend to an incident that is private, affects only a single customer’s own configuration, or where publishing detail would itself create a security risk.
Planned maintenance that we expect to cause noticeable interruption will be announced at least 48 hours in advance via the dashboard or email, and will where practicable be scheduled outside 08:00–20:00 UK time on business days. Planned, notified maintenance is excluded from Monthly Uptime measurement up to a maximum of 4 hours per calendar month.
Emergency maintenance to address security vulnerabilities, provider incidents or data-integrity risks may proceed without advance notice; we will post an update as soon as reasonably practicable. Customers should re-test critical workflows after making major configuration or integration changes on their side.
Support hours are Monday to Friday, 09:00–17:30 UK time, excluding English bank holidays. Within support hours we target: Severity 1 (service unavailable or a security incident) — first response within 4 hours; Severity 2 (major feature degraded with no workaround) — first response within 1 business day; Severity 3 (general questions, minor issues, configuration help) — first response within 2 business days.
Targets apply to requests sent from the business account email with enough information to investigate (account email, timestamps, affected page or number, and reproduction steps where relevant). Enterprise contracts may agree faster targets in writing. A response target is a commitment to engage, not a guarantee of resolution time where third-party providers are involved.
The availability commitment and service credits do not apply to: unavailability caused by your configuration, equipment, network or integrations; suspension for unpaid fees or breach; unlawful or unsupported use; failures of third-party services outside our reasonable control (including carriers, payment providers and AI model providers) where we have taken reasonable mitigation steps; trials and free accounts; beta or preview features; and events outside our reasonable control as described in the Terms of Service.
Service credits do not accumulate beyond the 25% monthly cap and cannot be combined with any other remedy for the same event.
Before go-live, verify billing, legal acceptance, knowledge, phone numbers, disclosure wording, escalation contacts, transfer destinations, docs and support ownership.
The availability measure concerns the production core service identified in this policy during the relevant monthly period. It does not mean every individual call, message, integration or browser request will succeed. A short failure may be visible to a Customer even if aggregate monthly uptime remains above the commitment. Conversely, an issue in a third-party feature may affect a Customer without meeting the defined core-service outage. We will describe the known scope of an incident rather than relying only on a single percentage.
Monitoring checks are evidence, not the only evidence. A Customer can report a period it believes was missed by monitoring, with timestamps and an affected path. We will investigate reasonable reports and correct a material measurement error. The credit calculation, eligibility window and exclusions in this policy govern an SLA claim.
We assess severity using the number of affected customers, the criticality of the blocked operation, data or security risk, and whether a workaround exists. The initial severity may change as new facts are confirmed. A public incident notice should identify the affected customer functions as clearly as the evidence permits; it should not reveal personal data or details that increase a security risk. We may use direct communication for a narrower issue or a sensitive account-specific incident.
During a material incident we will provide updates through the status or support channel appropriate to its scope. An update can say that investigation is continuing when the cause is not yet known. We will mark resolution only after the affected function is reasonably restored, and we may publish a follow-up explanation when there is useful verified information. A status page is not a substitute for any legally required notice.
A useful support report includes the affected function, approximate time, account or transaction reference, expected outcome, actual outcome and whether the problem is still occurring. The Customer should avoid sending passwords, full card numbers or unrelated personal data. A screenshot may help with a display fault, while a call or booking identifier helps with a transaction fault. We may ask for another example if the first does not let us reproduce or locate the problem.
The Customer should use urgent support or its own fallback path for work that cannot wait for an ordinary ticket. A posted response target is a target for initial human or meaningful automated triage, not a promise that every defect can be fully repaired within that period. We will explain when a provider or Customer action is needed to progress a case.
When a complete repair takes time, we may offer a temporary configuration change, a manual export, another supported route or a feature restriction to reduce harm. The Customer decides whether a workaround is suitable for its business and must keep any required human oversight. We should describe material limitations of a workaround rather than presenting it as full restoration. After the underlying issue is corrected, we may ask the Customer to reverse a temporary setting.
A Customer should keep its own continuity plan for urgent communications and regulated work. We will not make a Customer waive a valid service-credit claim merely to accept a workaround. Credits and refunds are applied according to their respective policies, and a service credit does not reduce a remedy that law says cannot be limited.
We may schedule maintenance to preserve security and reliability. Where practical, we will give advance notice of planned work likely to interrupt a customer-facing function and choose a lower-impact period. Emergency maintenance may need to begin immediately to address an active threat or severe fault. We will communicate the reason and affected functions as soon as reasonably safe. A notice of planned maintenance should not hide an unrelated unplanned outage.
We test changes proportionately to their risk and may roll back a release that causes material problems. Some changes to a connected provider or network cannot be scheduled by SIMCOAI. We will still investigate their effect on the Service and seek a workaround or explanation. The availability calculation treats exclusions as stated in this policy; calling an event maintenance does not by itself make every failure excluded.
A Customer seeking a service credit should identify the affected month, account, time window and function and submit the request within the claim period specified above. We will compare monitoring, incident and customer evidence. If an eligible shortfall is confirmed, we will calculate the credit under the stated formula and show it on the account or next eligible invoice. We should explain a refusal by reference to the measure or exclusion that applies. A credit is not a cash refund unless this policy or law says otherwise.
A Customer may challenge a calculation with additional evidence. We will correct a confirmed error. The claim process should be practical for a small business and should not require access to internal monitoring systems. A Customer that cannot use a credit because it is leaving may have a separate refund right under the Terms or Refund Policy.
A Customer should report a recurring fault with examples rather than assuming that each short event is unrelated. We may group events with a common cause for investigation and explain a corrective plan, including monitoring or a safer fallback where appropriate. A problem that falls outside the monthly availability calculation can still be a product defect requiring reasonable support. Conversely, a credit calculation should use the defined measure and should not be inflated by counting the same outage twice. We may use a post-incident review for a material event to improve controls. Its publication may omit security-sensitive or another Customer’s confidential details.
A service credit addresses a measured availability shortfall under this policy. A billing refund addresses an amount paid for an unused or undelivered service under the Terms and Refund Policy. We will avoid paying both for the same part of the same loss, but we will not use a credit to erase a separate statutory or non-excludable right. A Customer should be able to see how the calculation was made. A support response target is not a substitute for an availability commitment, and a monthly uptime figure is not a substitute for investigating a recurring defect. The applicable facts and clause determine the remedy.
A Customer may submit an error message, timestamp, affected route and business impact even if the public status page shows no incident. We should investigate a credible report and identify whether it is account-specific, a provider issue or a broader service fault. A private incident can still deserve direct communication and support. We should not create a public status incident merely to test our process, and we should not mark a confirmed customer-reachable outage as fully healthy without explanation. A screenshot shows what appeared on one device; logs and response checks help establish the actual scope and duration.