Group status
Each operating company publishes its own status page, maintained by the engineers who run that platform. This page aggregates them, so one look tells you whether anything in the group is affected.
Status by company
6 operating companies. Each row links to that company's own status page where one exists.
-
Operational
AgentTech Dialer
Dialer, CRM, recording, transcription, and compliance scoring. In production with paying agencies inside and outside the group. agenttech.io/status
-
Operational
Solved Telephony
Carrier interconnects, origination and termination, numbers and porting, messaging, routing, and AI Voice Agents. In production and sold externally. solvedtele.com/status
-
Operational
Solved Marketing
Lead acquisition and delivery across Medicare, life, and final expense, including delivery paths, pre-delivery filters, and pacing. solvedmarket.ing/status
-
Operational
Solved Enroll
Multi-product quoting and enrollment, including the AI Plan Recommender. In private beta with cohort agencies ahead of a 2027 public rollout. solvedenroll.com/status
-
Operational
Solved Solutions
FMO contracting, carrier appointments, hierarchy and licensing records, and commission reconciliation. solvedsolutions.insure/status
-
Not yet in service
Solved Insurance and Solved Re
Proprietary products and the MGA business behind them. In development, pending state approval, so there is no customer-facing service to report on yet. No status page yet.
Component-level detail lives on the company pages. Solved Telephony, for example, publishes a row per network component rather than one row for the whole network, and that is the level you want when you are debugging a specific call.
How this page is maintained
By hand, on purpose, and with the limits of that stated rather than hidden.
- Edited, not probed. There is no synthetic check behind this page. A person changes a status value and publishes, which is why it can lag a company page during a fast-moving incident.
- The company page wins. If this page and a company page disagree, the company page is correct and this one is stale. Treat this as an index, not as a source.
- Pre-launch is not an outage. Solved Insurance is in development pending state approval, so it is listed as not yet in service rather than as an incident.
- Private beta is still real. Solved Enroll is in private beta ahead of a 2027 rollout, and cohort agencies depend on it, so it reports like any other live platform.
- Maintenance is announced by the company. Planned work is scheduled and announced by the platform doing the work, because they know their own traffic peaks.
What this page is for
- One look
- Check every company in the group without opening five tabs.
- Then route
- Follow the link to the company page for component detail and incident history.
- Across two
- When an incident spans companies, the group coordinates and updates on one clock.
Group incident communication policy
What happens when something breaks, in the order it happens, and who you hear from at each step.
-
The company declares it
An incident is declared by the operating company that owns the affected platform, by the engineers running it rather than by a group function watching a dashboard. Their status page and their notification channels move first.
-
This page is updated
The company state is reflected here so anyone checking the group can see it. This step is manual and can trail the company page by minutes, which is exactly why the company page is the authoritative one.
-
Cross-company incidents get one owner
If the incident touches two companies, the group names a single owner across both. Updates go out on one clock, and affected customers get one account of what happened rather than two partial ones.
-
Updates at least hourly
At least every 60 minutes while an incident is open, even when the update is that we are still working. Silence during an incident is a choice, and it is not one we make.
-
Security incidents are notified directly
If an incident affects your data you get a direct notification naming what was affected and what we did, not a line on a status page. See the security page.
-
A closing note with the record
The final update names the affected components, the window, and what changed. Afterward you can have the records for the affected window rather than a summary of them.
Reporting something these pages do not show
Bring these four things and the first reply can contain an answer instead of a question.
Which company
Your best guess is fine. If you have no idea, the routing table on the help page usually settles it in one read.
An identifier
A call identifier, a lead identifier, a client record, or an application. One identifier is enough to pull the trail.
A timestamp
Time and time zone, or a UTC timestamp. A five-minute window is plenty.
The symptom
What you saw rather than what you concluded: a lead that never arrived, a call that failed, a quote that would not return, an export that came up short.
Email contact@solvedventures.io or call +1 (866) 415-6192. For anything security related, see the security page. To find the right company directly, start at where to get help.
FAQs
Status questions
Why does a holding company publish a status page?
Because a customer of one company often has no idea which company is responsible for what they are seeing. A lead that never arrived could be an acquisition problem, a delivery problem, or a dialer problem. This page is the single place to check all of them at once, and then it sends you to the company that publishes the authoritative detail.
Is this page authoritative?
No, and it does not try to be. Each operating company publishes its own status page, maintained by the engineers who run that platform, and that is the record. This page aggregates those states so you do not have to open five tabs. If the two ever disagree, the company page is right and this one is stale.
How is this page updated?
By hand. When a company opens an incident we change its status value here and publish the page. There is no probe behind it and no automatic rollup, which means it can lag a company page by a few minutes during a fast-moving incident. We would rather say that than imply a monitoring system that does not exist.
What happens when an incident spans two companies?
The group takes the coordination. One owner is named across both companies, updates go out on one clock rather than two, and the affected customers hear a single account of what happened instead of two partial ones that have to be reconciled. That is the main thing a group-level incident policy is for.
How often will I hear from you during an incident?
At least every 60 minutes while an incident is open, even when the update is that we are still working. The final note names the affected components, the window, and what changed. Customers of an individual company get that from the company; customers affected across two get it from the group.
How do I subscribe to updates?
Subscribe at the company whose platform you use, because that is where incident notices originate. If your operation spans more than one of them, email contact@solvedventures.io with the addresses you want on the list and we will include you on group-level notices as well.
Solved Insurance shows as not yet in service. Is that an incident?
No. Solved Insurance products are in development, pending state approval, and nothing is on sale, so there is no service to be up or down. It is listed here so the group picture is complete rather than quietly missing a company.
Something is broken but every page says operational. What now?
Tell the operating company rather than waiting for a page to catch up, because they can look at your account while you are still on the call. If you are not sure which company owns it, the routing table on the help page will tell you, or send it to us and we will work it out.
Something else? Contact us
Seeing something these pages are not?
Send an identifier and a timestamp. We would rather read your trail than guess which company owns it.