Skip to content
BuiltForProd
Talk to us
Support

Service levels

Three tiers, three channels, one escalation path, and a clear line around what support does not cover. The figures live in your agreement, not on this page.

What a service level means here

A service level is a written commitment about how quickly BuiltForProd acknowledges and works a request, measured in terms both sides define the same way. It attaches to a support tier, it applies to the platform we delivered, and its numbers are stated in your customer agreement rather than on a web page, because they differ by tier, severity and coverage hours.

Publishing a number that does not match your contract would be marketing, not a commitment. What this page does instead is define every term the contract uses, so the agreement holds no surprises.

Where the figures live

Response times, resolution targets and coverage hours are stated in each customer agreement. Ask for them during the commercial conversation; they are not negotiable after an incident, which is exactly why they are written down before one.

The three tiers

Support tiers are the three tiers of BuiltForProd Managed. All are optional and post-deployment.

On-Demand

Expert help by the hour, when you ask for it.

  • Consultation and support from BuiltForProd engineers on the platform we delivered.
  • Questions, reviews, second opinions and help working through a problem your team owns.
  • Access to the same engineers who build and deploy the platform.
Commitment

Pay per hour, minimum 10 hours. No standing commitment.

Service level

None. Best effort, as capacity allows.

Best for

A team that owns the platform and wants an expert available for the occasional problem.

Support SLA

The same engineers, with a written response commitment.

  • Everything On-Demand covers, governed by the service levels written into your agreement.
  • A severity scale, response commitments per severity, and defined coverage hours.
  • A predictable annual budget rather than a per-incident quote.
Commitment

A fixed-price, pre-paid block of at least 100 hours per year; hours expire after one year.

Service level

Yes. Severity, response times and coverage hours are stated in your agreement.

Best for

A team with compliance or contractual obligations that depend on someone answering.

Team Augmentation

Dedicated engineers inside your team, on your priorities.

  • Named BuiltForProd engineers working as part of your team, through your own tools and processes.
  • Work follows your backlog and your incident process rather than a request queue.
  • Platform ownership shared day to day, not handed over and forgotten.
Commitment

Part-time (4 hours a day, 20 a week) or full-time (8 hours a day, 40 a week), on a 6- or 12-month commitment, billed monthly.

Service level

Presence-based: the committed hours per day, as stated in your agreement.

Best for

An organization where production matters but nobody owns it full-time.

Team Augmentation is not hourly staff that follows an existing approach without question. Our engineers bring the way of building production that the platform encodes, which suits teams willing to adopt it. BuiltForProd Managed describes how the engagement works.

Channels

Support channels. Addresses and workspace details are given when your engagement starts.
Channel Use it for Available on
Email Anything that needs a record: a new request, a question with attachments, a change of scope. Every tier
Slack Day-to-day conversation, quick questions and coordination during an incident. Support SLA and Team Augmentation
Video Working sessions, architecture reviews and incident bridges. Every tier, by arrangement

Severity, in general terms

Your agreement carries the scale it uses. These are the plain-language meanings behind it.

Level What it means What to expect
Production down Your customers cannot use the service, or a control protecting production has failed open. Open in writing, start a bridge, and expect the request to be worked continuously under a tier that commits to it.
Production degraded Customers can use the service, but something is wrong, slow, or running without its usual safety margin. Worked during the coverage hours your agreement defines, with a workaround accepted as a resolution.
Non-production Anything in sandbox, dev or staging, and any question that is not costing you customers right now. Queued and worked in order. Most of these are answered from the documentation faster than from us.

State the severity you believe applies and the facts behind it. The engineer confirms it or changes it and says why, because severity decides which commitment applies.

The terms your agreement uses

Request

One problem or question raised through a support channel. One request has one severity and one owner at a time.

Severity

How much the problem hurts. Assigned when the request is opened, revised if the facts change, and confirmed by the engineer who picks it up.

Response time

The time from opening a request to an engineer acknowledging it and starting work. It is not the time to a fix.

Resolution time

The time from opening to a fix or a workaround that restores service. Where an agreement states a target, it is a target for that severity, not a promise that every root cause is removed inside it.

Workaround

A change that restores service without removing the root cause, such as promoting the previous release tag. A workaround can close the resolution clock while a follow-up request tracks the cause.

Coverage hours

The hours during which the clocks run for severities that are not covered around the clock. The agreement names the hours and the time zone.

Hours

The unit work is counted in against the 10-hour minimum or the pre-paid 100-hour block.

The same definitions are published in the documentation, under SLA definitions and service level agreements.

The escalation path

  1. Open the request in writing

    Email or the shared channel, with the stage, the impact, the run link and the error text. Start a call as well if you need one, but the written request carries the timestamp everything else runs from.

  2. Severity is confirmed

    You state the severity you believe applies; the engineer confirms it or changes it and says why. Severity decides which commitment applies, so it is agreed rather than assumed.

  3. An engineer owns it

    One owner at a time, named in the thread. Updates go into the same thread so the history stays in one place through a shift change.

  4. Escalate if it is not moving

    Ask for escalation in the thread. Your agreement names the escalation contacts and the point at which the engagement lead is brought in; there is no separate form and no queue to re-enter.

  5. Close with a write-up

    A resolved incident ends with what happened, what fixed it, and what stops it recurring. If the prevention is a change to the platform or the documentation, it becomes a pull request.

What is not covered

Cloud provider availability

Your cloud provider runs its own services under its own service commitments. Our commitment is about our response, not their uptime, and no support tier can change what a region does.

The uptime of your own application

We deploy and, under Managed, help operate the platform. What your customers experience also depends on your application code and your own operations, and the shared responsibility model draws that line explicitly.

Application code, product design and data models

When the root cause is in your application rather than in infrastructure, security, delivery or operations, we will say so. That is a referral, not a billable investigation.

Systems we did not deliver

Support covers the platform BuiltForProd built: the foundation, the Blueprints, the pipelines and the documentation. Bringing another estate into scope is a new engagement, not a ticket.

Ownership and final approval

Ownership of the accounts, the root mailbox, the repositories, the data and the final approval on production changes never moves to BuiltForProd, under any tier.

The shared responsibility model sets out what your cloud provider owns, what BuiltForProd owns and what stays with you. Website terms cover this site; your engagement is governed by your customer agreement.

Service level questions

What are BuiltForProd response times?

Response times are stated in each customer agreement rather than published on this site, because they differ by tier, by severity and by coverage hours. What is fixed everywhere is the meaning of the terms: response time is time to acknowledgment and the start of work, resolution time is time to a fix or a workaround, and severity is agreed when a request is opened.

The definitions

Which tier has a service level agreement?

Support SLA is the tier governed by a service level agreement. On-Demand carries no response commitment and is help as capacity allows, and Team Augmentation is a commitment of dedicated engineer time per day rather than a per-request response window.

BuiltForProd Managed

How do I escalate an incident?

Ask for escalation in the same thread as the original request. Your agreement names the escalation contacts and the point at which the engagement lead is brought in, so escalation never means re-entering a queue or opening a second ticket.

Does a support tier guarantee my application stays up?

No, and no support tier from anyone can. A service level agreement governs how quickly we respond, not whether your cloud provider has an outage or whether your application handles the traffic it receives. What the platform does is make failures visible, recoverable and reproducible, which is a different and more honest promise.

Shared responsibility

Can we start without a support tier and add one later?

Yes, and many customers do. A deployment hands over the repositories and the full documentation set whether or not you buy a Managed tier, and teams commonly start with On-Demand hours and move to a Support SLA when a customer contract or an audit makes a written response commitment necessary.

How engagements are quoted

Which tier fits your team?

Tell us who owns production today and what you are contractually obliged to promise your own customers. That answer usually picks the tier for you.

Talk to us BuiltForProd Managed