Your customers stay yours

This page is written for an owner deciding whether to trust a platform with customer data, an agreement, and a route - not for a security team filling out a vendor questionnaire. No certification claims and no uptime promises appear here; only what the database is actually built to do.

Isolation happens at the row, not just at login

Most software keeps different customers' data apart by controlling who can log in and what screens they see. That matters, but it is not where Service Biz Hero draws the real line. Every table carries an account identifier, and the database itself - not the application code sitting on top of it - refuses to return or accept a row that doesn't belong to the account asking for it. That protection is turned on and enforced at the database level, so a mistake in a screen or a report cannot accidentally show one account's customers, routes, or invoices to another.

That distinction matters because application-level mistakes happen - a forgotten filter, a copy-pasted query. A row-level rule enforced by the database itself does not depend on every screen remembering to ask correctly; it refuses the wrong request regardless of how it was made.

The record of what happened cannot be rewritten

Every change of consequence - a status change, a price adjustment, a commission override, a canceled message - is written to an append-only record. Rows do not get edited or deleted after the fact; they get superseded by a new entry, and the old one stays exactly as it was. There is no "undo" that quietly erases what actually happened, and no account role - including an owner's own login - can rewrite that history after it's written. If a dispute ever comes down to "what actually happened here," the answer isn't a memory or a guess; it's a record that cannot have been altered.

Consent, honored per customer, every time

A customer's consent to be contacted is stored per customer and checked again every single time a message is about to go out - not assumed from a prior send or a signup form filled out once. The messaging engine has no path that skips this check. If a customer has not consented to a channel, a message on that channel simply does not get queued, regardless of how urgent the reason seems.

What export means

Your data is exportable on request. That is not a policy that could be revoked or delayed at someone's discretion - it follows directly from how the data is isolated in the first place: your account's rows are cleanly separable from everyone else's because the database was built that way from the start, not stitched together after the fact. If you ever need your customer list, job history, or agreement records outside the platform, that data is yours to take.

Who can see what

Access follows role, not platform. An owner sees everything for their account: every route, every agreement, every invoice, every commission calculation. A dispatcher works the route board, the billing-candidate queue, and customer communications - the tools the office needs day to day. A technician sees their own assigned route, the job checklist, and the photos and notes they capture - not another technician's day, and not the office's billing or commission detail. Every one of those boundaries is enforced the same way the tenant boundary is: at the row, by the database, not left to a screen to hide a button and hope nobody finds the underlying page.

What "keeping your customers yours" actually requires

Saying a platform won't hold your data hostage is easy; building the database so that promise can't quietly be broken is the harder part. Because isolation is enforced at the row and not by a rule an application developer has to remember to apply, there is no code path anywhere in the platform that can accidentally blend one account's customer list, agreements, or job history with another's - the database itself is what refuses the request, not a policy document.

Why this is described this way

None of the above is a certification, an audit result, or a promise about how long the service stays running - those are different questions, and we are not going to answer them with claims we cannot back up today. What's written here is the actual mechanism: how data is kept apart, why the history can't be quietly edited, how consent gets checked, and what leaving with your data looks like. An owner deciding whether to trust a platform deserves the mechanism, not a badge.