The best reply to a customer during an outage is a short one, sent early, by someone who can see the whole picture. The person answering knows the check failed at 07:12, knows which parts of the product it touches, knows the status page already says so, and can see that this customer raised something similar in March. The reply takes a minute, the customer feels looked after, and nobody had to go and ask anyone for the details.
That reply is hard to write when the details live in different products. Support tooling tends to be bought one purchase at a time, each for a sound reason, and each product keeps its own record of what is happening. The helpdesk knows the customer, the monitor knows the check, the on-call tool knows who was paged, and the status page knows what has been said in public. What follows is a single incident traced through a common stack: where the customer's context is dropped, what that stack costs, and what organising the tooling around the customer would change.
The stack we'll follow
Take a B2B SaaS company running Help Scout for the shared inbox and help centre, Atlassian Statuspage for the public status page, PagerDuty for on-call, and UptimeRobot for checks. Each of those is a good product, and each was bought to solve the problem in front of the company that week, probably months or years apart. Each is also priced for a company where that job belongs to a department.
Nothing in what follows is a criticism of any of them. What matters is what happens to a customer's problem as it crosses between them.
One incident, followed through the hand-offs
It is 07:12 on a Tuesday and the API has started returning errors.
The check fails. UptimeRobot notices within its check interval and fires an alert. Its PagerDuty integration unlocks on the Team plan, so the alert can travel onward carrying the monitor's name, the URL and the status code. It cannot carry anything about who is affected, because a monitor holds no record of who the customers are.
The alert becomes an incident. PagerDuty pages whoever is on call. It opens an incident, records the acknowledgement at 07:14 and starts a timeline. That timeline is about the alert and the responder, which is what an on-call product is for. The customer still does not exist anywhere in this story.
Someone updates the status page. Statuspage is its own product with its own login, so a human has to go there and write a post. The people who can write it are usually the people fixing the thing, so the page lags, and when it is written it is written from memory of what the PagerDuty timeline says. The subscribers who receive it are a list Statuspage holds, separate from the customer contacts in Help Scout even though they are largely the same people.
The ticket arrives. At 07:31 a customer emails. Help Scout has their whole history and nothing about the incident. Whoever picks up the ticket has to go and find out what is happening: check Slack, check the status page, ask the engineer who is busy. Then they write a reply by hand restating what the status page says, and again for the next ticket, and the one after. When the incident resolves at 08:05, none of those tickets change. Someone has to remember which conversations were about the outage and go back to each one.
The integrations between these products do work; that is not the problem. They carry events and alerts from one to the next. What they cannot do is give the products one shared record of the problem, so each keeps its own version, and the person replying to the customer is the one who reconciles them, by hand, during the exact half hour when there is least time to do it.
The cost of that is not dramatic on any single day. It is a reply that goes out at 07:50 instead of 07:35, a status page that says "investigating" for forty minutes after the fix, a follow-up that never gets sent because the ticket was closed on Tuesday and the root cause written up on Thursday. Customers notice these things cumulatively, and form their view of a company from them.
What this stack costs
Buying one product at a time shows up in the bill as well as in the hand-offs. To put numbers on it we used our own support stack cost calculator, which takes each vendor's public list price, picks the cheapest published plan that fits the numbers you give it, counts free tiers when they fit, and adds seat or subscriber add-ons only where the vendor publishes a price for them. The figures below are on monthly billing, converted from US dollars at £0.78 to the dollar, before VAT, and were checked on 3 September 2026. Treat them as a floor rather than a quote; negotiated rates and startup credits are not modelled.
The example holds two things steady, 250 status page subscribers and 15 monitors, and varies the two that actually move the bill: how many people are on the team, and how many customer contacts they support.
| Scenario | Help Scout | Statuspage | PagerDuty | UptimeRobot | Stack per month |
|---|---|---|---|---|---|
| 5 people, 100 contacts | Free | Hobby | Free | Team, plus two extra login seats | about £88 |
| 5 people, 250 contacts | Standard, five seats | Hobby | Free | Team, plus two extra login seats | about £205 |
| 6 people, 250 contacts | Standard, six seats | Startup | Professional, six users | Team, plus three extra login seats | about £415 |
At five people and 250 contacts the stack comes to about £205 a month. Help Scout's free tier stops at 100 contacts helped in a month, so the company is on Standard at a price per seat. Statuspage needs the Hobby tier for 250 subscribers and a custom domain. PagerDuty is free for up to five users. UptimeRobot's Team plan includes three logins, so the other two people are paid seats.
Now hire one more person. The same company at six people is about £415 a month, and every part of that jump is a headcount cap rather than a customer number. PagerDuty's free tier ends at five users, so everyone moves onto Professional at a price per user, which is the single biggest step. Statuspage's Hobby tier allows five team members, so the page has to move to Startup. Help Scout and UptimeRobot each add a seat. One new colleague roughly doubles the bill, and none of that increase has anything to do with the company having more customers.
It is worth being straight about the smaller end of the table. At five people and 100 contacts the same stack costs about £88 a month, because Help Scout's and PagerDuty's free tiers both fit. Free tiers are genuinely good at small numbers. The cost arrives with growth in the team: each product in the stack has a seat or team-member meter, and each of those meters ticks when a colleague is added, whether or not there are more customers to support.
How many tools does a small SaaS need for support?
There is no correct number, and the counts that get quoted are for whole companies rather than support teams. They still describe the environment any support stack sits inside. Zylo's 2025 SaaS Management Index puts it like this:
"Spend and portfolio size vary widely by company size. Smaller companies (1-500 companies) [sic] spend an average of $11.5M on SaaS and use 152 apps, while large enterprises (10,000+ employees) spend an average of $284M and use 660 apps."
Zylo, 2025 SaaS Management Index, 16 January 2025
A year later the same index reported that organisations "leave an average of 36% of their SaaS licenses unused" when measured against industry-recommended utilisation levels (2026 SaaS Management Index, 29 January 2026). The buying keeps running ahead of the using.
For support specifically, the more useful question is how many places one customer's problem has to be written down before it is answered. A stack is the right size when the person replying can see the failed check, the incident, what has been published, and the customer's own history from the screen they reply on. Whether that takes one product or several is secondary; it is the shared record that matters.
What "unified around the customer" means in practice
The phrase gets used loosely, so here is a concrete version. A stack is unified around the customer when the customer is the record everything else attaches to, rather than something each product keeps its own partial copy of. In the Tuesday morning story, that would look like this.
A failed check raises an incident on its own, and the incident knows which parts of the product it affects. The status page is a view of that incident, so writing the update for the team and publishing it for customers is one action rather than two products. The subscribers who receive it are the same contacts the support inbox already holds. A ticket that arrives while the incident is open is linked to it, and whoever replies sees the incident timeline and the customer's history on the same screen, with the reply half-written. When the incident is resolved, the tickets attached to it show it, so whoever sends the follow-up can see which conversations were about the outage without having to remember.
Two further properties follow from taking the customer as the unit. The first is that the whole team can be in the tool, including the engineer on call and the founder who still answers tickets on a Friday, because a bill that follows customer contacts does not go up when a colleague is added. The second is that the record persists: when the same customer writes in three months later, the person replying sees the earlier incident and the earlier conversation, and answers with both in front of them.
None of this requires a single product. A team could, with enough integration work, wire its existing tools into something close to it. The shared record is the property that matters, however a team arrives at it, and the Tuesday morning is a reasonable test of whether it is there.
Where StayUpfront fits
StayUpfront is built on that shared record. Web checks raise incidents automatically, incident updates go to the status page and its subscribers as part of writing them, support tickets link to the incidents they are about, and Una, the AI in StayUpfront, suggests the link and drafts a reply for a person to review and send. On-call schedules, escalation paths, the customer's history and the docs sit alongside, in the workspace the whole team already uses every day.
It is priced by the customer contacts you support, with the whole team included. The example company, at 250 contacts, would be on Growth at £149 a month at the standing price, against about £205 for the stack at five people and about £415 at six. At 100 contacts it would be on Starter at £79, against the stack's £88, which is the honest size of the gap while free tiers are doing the work. The pricing page has the rest of the plans and the numbers behind them. At the moment early customers are on founding prices, which put Growth at £99 and Starter at £49, and those are the prices that stay with an account for as long as it keeps them. All figures ex-VAT.
To check the maths against your own numbers, the calculator shows every vendor's plan and the reason it was chosen, including the scenarios where a free tier wins. To see the Tuesday morning story run end to end, there is a 14-day free trial with nothing charged until it ends.