Care Plan
We run it. You do not. Every system we build for a business in metro Detroit or across Michigan is watched after launch, repaired before you notice, kept current with the vendors and reported on one page a month, by a person who knows your build.
Talk to usIn short
The build is how it starts. The running is the product: monitors that treat silence as an alert, repairs done before the business opens, vendor changes absorbed on our side, and a monthly page that says what ran, what was caught and what it produced.
- Silence is an alert, at any hour
- Repaired and replayed before you open
- Vendor API changes absorbed on our side
- One page a month, in accounts you own
Why launch is the easy part
It broke at 3 am on a Sunday. Nobody at your business was looking.
A calendar vendor renames a field. A phone provider retires an endpoint. A messaging platform changes what a partner is allowed to do. None of it announces itself, and the system that depended on it simply goes quiet. Found on Monday, that is a weekend of bookings gone. Found at 3:08 on Sunday, it is a note in the morning.
So we treat silence as an alert. Every system we build reports that it is working, the moment it stops reporting we are told, the repair is done and the missed work replayed before the business opens, and the month closes with one page that says what ran, what was caught and what it produced. The accounts, the logs and the documentation are yours the whole time.
Illustrative. The night is the point: the plan is for what happens when nobody at your business is looking, and the page is how you find out it happened.
In the work
Watch, repair, keep current, report, document, answer
Monitored, so silence is an alert
Every system reports that it is working, and the moment one stops reporting, that is the alarm. A calendar that receives no bookings on a Tuesday afternoon is a fault until proven otherwise, not a quiet day.
Repaired before you notice
The alert goes to us, not to you. Most repairs are done before the business opens and arrive as a note saying what happened, what was done and what was replayed, rather than as a problem you have to describe.
Kept current with the vendors
The calendar, the CRM, the phone system and the messaging platforms change their APIs without asking. Each change is applied on our side, tested, and never becomes your problem.
Reported monthly, on one page
What ran, what was caught, what was changed, and the numbers the system exists to produce: calls answered, bookings made, invoices paid, messages replied to. One page, the same shape every month, with the detail a click away in accounts you own.
The documents, kept
Every rule, every integration and every change, written down as it happens. The documentation is how a repair takes minutes and how whoever comes next can read the system without us.
A person who knows your build
One number, one person who has read your documentation, not a queue. When you want the schedule changed, a rule adjusted or a new season set up, that is who you call.
Getting there
Handover, watch, repair, report, review
- 01
Handover
The system goes live with its documentation, its monitors and its alerts already in place. Nothing is handed over that cannot be watched.
- 02
Watch
Every system checks in on a schedule and every check-in is logged. The first sign of trouble is usually a missing heartbeat, and that is enough.
- 03
Repair
The alert is worked at once, the cause is fixed rather than restarted, anything that was missed while it was down is replayed, and the note is written.
- 04
Report
The monthly page, read with you the first few times, then sent. The questions it raises become the changes for next month.
- 05
Review
Each quarter, what the system is doing against what it was built to do, and what the next season needs from it, agreed before the season arrives.
Fitted work
What comes up here, specifically
The first freeze
The night the temperature drops across metro Detroit, a furnace company's call volume triples between midnight and six. The front desk is watched for capacity that week, not just for uptime, and the waitlist rules are checked before the cold arrives.
The Sunday update
Vendors ship changes at the weekend, when nobody at a small business is watching. Monday morning is when it would have been found. It is found at 3 am on Sunday instead, and repaired before Monday.
The seasonal business
A marina, a landscaper or a snow contractor runs a full season and a quiet one. The systems are set to the season: the reminders, the messages and the schedule rules change on the dates the business does, and the report says so.
The new hire
Staff change; access changes with them. A new person is given what their role allows and nothing else, the departed one is removed the same day, and the knowledge assistant already knows the answers the new hire is about to ask.
Right time when
When this is worth doing
A good fit
- You run a system we built, or one somebody else built and left
- Nobody at the business would know a system had stopped until a customer said so
- The vendors you depend on change things and you find out afterwards
- You want one page a month rather than four dashboards
Not a fit
- You want to run and repair it yourself, which the documentation is written to allow
- The system is a product with its own support, in which case that is who to call
- Nothing depends on anything else, which is rare and worth checking
Scope
What we do not do
Fail silently
A system that stops and says nothing is the failure mode we build against. Every system reports, every gap is an alert, and every alert is logged whether or not it turned out to matter.
Change things without telling you
Repairs are noted the morning after; anything that changes a rule or a message a customer sees is agreed with you first. The monthly page lists every change, including the ones you did not ask for.
Hold anything hostage
The accounts, the automations and the documentation are yours. If the care plan ends, the systems keep running where they are, and the documentation is written so whoever comes next can pick them up.
Reasonable to ask
Before you sign up
What does the care plan cover?
Everything we built: the monitoring, the repairs, the vendor changes, the monthly report, the documentation and the person to call. It does not cover new work, which is scoped separately, and it does not cover the vendors' own outages, which it watches and reports but cannot fix.
What counts as a repair, and what is new work?
A repair puts back what was agreed and working: a broken integration, a changed API, a rule that stopped firing. New work changes what the system does: a new channel, a new automation, a new report. The line is written into the handover, and anything on the new-work side is quoted before it starts.
How quickly is something fixed?
The alert is worked as soon as it fires, at any hour, and most repairs are done before the business opens. When a vendor is down, the report says so and what was replayed once they came back. We do not promise a number of minutes; we show the log.
Do we see the monitoring ourselves?
Yes. The monitors and the logs live in accounts you own, and the monthly page is a summary of what you could read on any day. Nothing about the running of your systems is hidden from you.
What if we stop the care plan?
The systems keep running where they are, in your accounts, with their documentation. What stops is the watching, the repairs and the report. Most clients who leave do so because they hired someone to do exactly that, and the documentation is written for that person.
Tell us what you are running.
The systems, who built them, and the last time one of them stopped without anyone noticing. We will tell you what watching them would look like, what the first monthly page would say, and what has to be documented before it can start.
Talk to us