Support and service level
An MSP is asked for commitments by its own clients that it cannot make unless Sigil makes them first. The partner agreement carries two of them: an uptime figure with credits behind it, and a response time on escalations.
Both are obligations in the agreement rather than sales copy, and both apply for as long as you are an active partner. Neither is offered to a direct customer: the terms of use make no availability commitment, and the published support page states an aim rather than a target you can hold anyone to.
The phrase “active partner” is doing real work in that sentence. Both commitments end if the partnership does, which is what leaving the programme covers.
Who answers a client’s question
Section titled “Who answers a client’s question”Support is split, and the split follows what each side sells.
| Kind of request | Who handles it | Target |
|---|---|---|
| General usage, configuration and day-to-day queries from your clients | You, as first line | Yours to set |
| An issue affecting the availability of the service itself: a bug, a regression, an outage | Escalate to Tophhie Cloud | Response within four business hours |
| General product queries you would rather not answer yourself | Tophhie Cloud, at lower priority | None |
First-line support is the part of the service you sell, so your clients should come to you for it. The product says so too: Help in a managed client’s portal names you as the people to ask, above the Tophhie Cloud address rather than instead of it, so a client who cannot reach you is not left at a dead end.
It names you and stops there. Sigil holds no support address for a partner, and guessing one from your domain would send a client’s problem into a mailbox that may not exist, so the dialog tells them to contact you however they normally do. Whatever route you have given your clients is the one they will use.
That is also why the agreement does not stop you passing a general product question on: it is handled, just behind anything that affects whether the service is up.
Business hours are Monday to Friday, 9am to 5pm UK time, excluding public holidays in England and Wales. A response means an acknowledgement and an initial assessment. It is not a commitment to have fixed the problem in four hours, and the agreement says so rather than leaving it to be inferred.
The uptime commitment
Section titled “The uptime commitment”Sigil commits to a monthly uptime of 99.9%. Availability of the service is Tophhie Cloud’s responsibility, and where a month falls short of that figure you are entitled to a service credit.
Uptime is measured over each calendar month, as the proportion of the month in which the service was available. What measures it is an independent external monitor rather than Sigil’s own reporting: it renders a signature end to end every few minutes from more than one region, and counts the month against whether a valid signature came out. See infrastructure, which also covers the public status page where the current state and any open incident are published.
The credit is a percentage of your fees for the month the shortfall happened in:
| Monthly uptime | Service credit |
|---|---|
| Below 99.9%, at or above 99.5% | 10% |
| Below 99.5%, at or above 99.0% | 25% |
| Below 99.0%, at or above 95.0% | 50% |
| Below 95.0% | 100% |
For partners, this section of the agreement replaces the availability clause of the general terms of use, which aims at a reliable service without guaranteeing one. That replacement is what makes the figure an obligation rather than an aspiration.
What does not count as downtime
Section titled “What does not count as downtime”Two things are excluded from the calculation.
Scheduled maintenance is excluded where reasonable advance notice has been given.
So is unavailability of third-party services outside Tophhie Cloud’s reasonable control, which in practice means Microsoft 365 and the Microsoft Graph API, and Cloudflare. Sigil reads your clients’ directories through Graph and runs on Cloudflare’s edge network, so an outage at either is visible to your clients without being something Sigil can fix or credit. See infrastructure for what sits where.
An interruption to Sigil affects signature management rather than mail flow. Sigil never gates the sending of email, so users keep sending during an outage; what they lose is the signature being applied and the portal being reachable.
Claiming a credit
Section titled “Claiming a credit”Write to support@usesigil.app within 30 days of the end of the affected month.
The credit is applied to your next invoice. Credits are not paid out in cash.
The 30-day window is the part worth diarising. A credit is claimed rather than applied automatically, so a month that qualified and went unclaimed stays unclaimed once the window closes.
An agreed credit appears on your Partner billing page as a service credit, carrying the month it settles and the reason it was agreed, and comes off a following invoice. That record is what makes a credit explicable months later, when the invoice it reduced is the only thing anybody can still see. See invoices and credits.
No minimums
Section titled “No minimums”There is no minimum volume and no minimum spend. You are billed monthly in arrears for the mailboxes you actually manage, so a month in which you manage none costs nothing. See partner billing for how the count is made.
Accepting the agreement
Section titled “Accepting the agreement”Both commitments on this page take effect when a partner Owner accepts the agreement, and a partner who has not accepted cannot take a client on at all. The mechanics, along with the data processing agreement the same acceptance covers, are in the partner agreement.