Built to keep your agency's data yours

Your $50/month agency plan includes 2 staff seats from day one — no separate setup fee, no “starter” tier missing features. Extra staff seats are $5/month each if your office team grows.

Field agents and client contacts never count toward your seat total. Invite as many as your agency actually needs, and none of them add to your bill.

What a “seat” actually covers

A staff seat is a login for someone doing office-side work in Trackr — assigning jobs, reviewing job requests, managing clients, running reports. It’s a different thing from a field agent’s login or a client’s login, both of which are free and unlimited regardless of how many staff seats your agency is paying for. The $50/month plan is built around the assumption that most agencies start with a small office team and grow that side more slowly than they grow their field roster.

Why agents and clients aren’t metered

A repossession or process-serving agency’s field roster can swing seasonally, and a debt collection agency’s client base can run into the hundreds. If either of those counted toward a seat limit, the pricing would punish agencies for exactly the kind of growth Trackr is meant to support — more agents on the road, more clients sending work through. Instead, only office-side staff logins count, so bringing on ten more field agents or fifty more clients doesn’t change your monthly bill at all.

What it costs to grow the office team

Two seats is enough for a lot of small agencies to run day-to-day — one person managing jobs, one handling admin or invoicing. When an agency does need more office logins, extra seats are $5/month each, added individually rather than forcing an upgrade to a bigger bundled tier the agency doesn’t need the rest of. There’s no separate onboarding fee or feature gate tied to seat count either — a two-seat agency and a ten-seat agency see the same feature set.

How this plays out for a growing agency

In practice, an agency’s cost predictability comes from staff seats being the only thing that moves. Field agents and clients can be invited freely as the agency wins more work or takes on more referrers, and the $50/month base plus $5 per extra staff seat is the whole picture — no usage-based job fees, no per-agent charges layered on top. A two-person agency — one person in the field, one running the office — can be fully set up in Trackr on the base plan without hitting a seat limit that forces an unplanned upgrade. Optional add-ons like Xero sync are priced and turned on separately from seat count too, so switching on invoice syncing doesn’t quietly push an agency toward needing an extra staff seat it wouldn’t otherwise need — the two costs move independently.

A lot of software vendors can technically look at your data whenever they want — it’s just a matter of policy, not a technical limit. Trackr’s support access is built the other way around: our own support team can’t view your jobs, clients or financials, and can’t log in as one of your users, without someone at your agency explicitly granting access first.

When access is granted, it’s time-limited to a capped window (an hour), revocable by your agency at any time, and fully logged in your own Agency Settings — so it’s a real record, not just a promise in a privacy policy.

Why “we could technically see it” isn’t good enough

A lot of SaaS vendors are honest that their support staff can access customer data — it’s just framed as a policy commitment, not a technical limit. For agencies handling process-serving, repossession or debt-collection work, that distinction matters: the data involved is home addresses, financial circumstances, vehicle details and, often, information tied to a court order. Trusting a vendor’s privacy policy to be the only thing standing between that data and their support team is a weaker position than most agencies would choose if they thought about it directly.

What “explicitly granting access” looks like

By default, nobody on Trackr’s support team can view your jobs, clients or financials, or log in as one of your users. If your agency does need help troubleshooting something, someone at your agency grants access from your own Agency Settings, and that’s what opens the door — not a support ticket alone, and not an internal override on Trackr’s side.

Time-limited and logged, not just switched on

Once granted, access is capped to a limited window — an hour — rather than staying open indefinitely once someone remembers to turn it off. It can be revoked from your side at any time before that window closes, and the grant itself is logged in your Agency Settings, so there’s an actual record of when access was given and by whom, not just a setting that quietly reverts a policy back to normal.

Why this fits agencies handling sensitive work

For agencies whose clients or referrers ask pointed questions about data handling — the same clients who care where the servers physically are — being able to say support access is opt-in, time-boxed and logged is a concrete answer rather than a policy statement to take on faith. It sits alongside NZ-based hosting as one more thing an agency can point to when a client’s own compliance requirements are the reason they’re asking in the first place.

Data isolation between agencies in Trackr isn’t a matter of hiding things in the interface — every job, client and financial query is scoped to your agency at the point it’s made. There’s no path that lets one agency see another’s data, outside the agency-connection feature you explicitly choose to turn on yourself.

Why isolation is structural, not a setting

In a lot of software, “your data is separate from other customers’ data” really means a permission flag somewhere that could, in theory, be misconfigured or switched off by mistake. That’s not how it works in Trackr. Every query for a job, a client, a note or a financial assessment is scoped to the requesting agency at the point the query is made, not filtered out of a shared result set afterwards. There’s no admin toggle to accidentally leave off, because there’s no broader pool of cross-agency data for a toggle to hide in the first place.

What it means for the people actually using Trackr

Staff, field agents on the native iOS and Android apps, and clients logging into their own portal all sit on the same underlying system, but none of them can see past their own agency’s boundary. A field agent working a job for Agency A has no path to Agency B’s jobs, even though both agencies might be running on the exact same Trackr infrastructure at the same time. Client logins work the same way — a client only ever sees the jobs and records that belong to the agency relationship they’re part of, regardless of how many other agencies happen to be using Trackr.

Where agencies do share visibility — and why that’s opt-in

The one deliberate exception is the agency-connection feature: two agencies that genuinely work together, for example a referring agency and a subcontracted agency handling the on-the-ground work, can choose to connect their accounts and share specific job information across that connection. Both sides have to opt in for that to happen. Outside of a connection either agency has actively set up, there’s no default visibility into another agency’s data at all.

Why this matters for process serving, repossession and debt collection

Agencies in this space are frequently competing for the same referral work from the same law firms, finance companies and debt collection clients, sometimes while also subcontracting to each other on individual jobs. That combination — competitors who are occasionally also collaborators — makes data isolation more than a technical checkbox. A firm referring sensitive defendant, asset or financial information to an agency needs confidence that using a shared platform doesn’t mean that information is visible to a rival agency also using it. Structural, database-level isolation is what makes that a straightforward “no” rather than a policy promise.

Field work happens with patchy signal, which means a submission occasionally has to be retried. Trackr is built so that retrying a dropped submission — an attempt, a repo report, a financial assessment, or an invoice — never creates a duplicate. You get exactly one record for the thing that actually happened, however many times the request had to be retried to get there.

Why duplicate submissions happen in the field

Field agents work from wherever the job actually is — a car park, a rural driveway, the basement of an apartment building — not always somewhere with a reliable signal. A submission can time out or fail to confirm partway through, whether it’s logging an attempt, filing a repossession’s vehicle condition report, recording a debt collection’s financial assessment, or closing out a job with an invoice. When that happens, the natural response is to hit submit again, and in most systems that’s exactly the moment a duplicate gets created — two attempt logs for the same visit, two invoice lines for the same job, both needing to be spotted and cleaned up later.

What retrying actually does

In Trackr, an agent doesn’t have to guess whether their first tap went through before deciding whether to try again. If it did, retrying doesn’t add a second record. If it didn’t, retrying is what creates the one record that actually counts. Either way, the agent ends up with exactly one confirmed submission and can move on to the next job without waiting on a signal check or calling the office to ask whether something came through twice.

Why this matters more for financial records than a missed note

A duplicated note is an annoyance. A duplicated financial assessment or invoice line is a bigger problem, because debt collection and repossession work runs on records with real financial and legal weight. A debtor’s details recorded twice with slightly different notes is confusing at best; a client billed twice for the same job means someone at the agency has to notice the error, apologise, and manually credit it back — not a disaster on its own, but exactly the kind of small, avoidable mistake that erodes a client’s confidence in an agency’s admin at volume.

One clean record for office staff to work from

The practical upshot is that office staff opening a job can trust its attempt history and financial records reflect what actually happened on the ground, not what happened plus however many retries a patchy signal forced. That same reliability carries through to jobs that started life as a request through the embeddable quote calculator or were converted from an inbound enquiry — by the time staff are reviewing and invoicing, the record they’re looking at is the real one, not a set of near-duplicates to reconcile first.

A password alone is one point of failure. Trackr’s login is backed by a one-time verification code sent to your email address on top of your password, so getting into an account takes more than just knowing (or guessing) the password.

What the login flow looks like

Signing in still starts the way it always would — email and password. The difference is what happens next: Trackr sends a one-time verification code to that email address, and it has to be entered correctly before the login completes. Knowing the password gets you halfway; without access to the inbox it was sent to, that’s where it stops. It’s a step added to every login, not just ones from an unfamiliar device or location, so there’s no gap in coverage depending on where or how someone’s signing in.

Why this matters for the data agencies hold

Process-serving, repossession and debt-collection agencies work with information that’s genuinely sensitive on both sides — home addresses, vehicle and asset details, financial circumstances, and details tied to a live legal or enforcement action. A password on its own is one point of failure standing between that data and anyone who guesses it, phishes it, or finds it reused from another breach — and reused passwords are common enough that a breach at some unrelated site can end up being the way someone gets into an account here. A one-time code doesn’t make a guessed password harmless, but it does mean a guessed or leaked password alone isn’t enough to get in.

Covering both the office and the field

Trackr is used two ways day to day — the web app for staff working jobs and clients from a desk, and the native iOS and Android apps field agents carry with them. All of them check in against the same account system, so the same one-time-code step applies whichever way someone’s signing in, on whichever device. That matters in practice because field agents are often signing in from personal or shared devices out on the road, not a managed office computer with its own layer of protection — the login itself needs to hold up on its own, regardless of what device it’s coming from.

Part of a broader access model

Login security is only one layer. Once someone is in, agency data isolation scopes every query to their own agency at the database level, so a compromised login at one agency doesn’t expose another’s data. And Trackr’s own support team can’t view your jobs, clients or financials — or log in as one of your users — without your agency explicitly granting time-limited access first. Secure login is the first checkpoint; it isn’t the only one standing between your agency’s data and the wrong hands.

Agency and client data in Trackr lives in AWS’s Asia Pacific (New Zealand) region. Data doesn’t leave New Zealand except for the specific third-party services a feature you’ve opted into genuinely needs — address autocomplete, AI rewrite, invoice sync, payments.

What “hosted in New Zealand” means in practice

Every job, client record, financial detail and audit trail your agency creates in Trackr is stored on cloud infrastructure physically located in New Zealand, not routed through a data centre in Australia, the US or Europe by default. That’s true whichever way your team is working — the web app in the office, or the native iOS or Android app a field agent is using to log a job on-site. Both write to and read from the same New Zealand-based infrastructure, so there’s no separate “field data” path that leaves the country while office data stays put. It’s the same region, the same infrastructure, for everyone on your agency’s account.

Why this matters for process serving, repossession and debt collection

Agencies in these industries handle information that’s more sensitive than most — home addresses, vehicle and asset details, financial circumstances, and in many cases details tied directly to a court order or an enforcement action. Where that information physically sits isn’t an academic question for a lot of agencies; it’s something their own clients, referrers or legal counsel ask about directly, sometimes before anything else. Being able to answer “New Zealand” plainly, rather than “somewhere in our vendor’s global cloud,” removes a question before it gets asked twice.

Who this reassures

It’s typically the more compliance-conscious end of the client base that raises data location as a condition of working with an agency at all — government-adjacent contracts, corporate clients with their own data-handling policies, or referrers who simply won’t sign off on a supplier until they know where the data goes. For agencies chasing that kind of work, NZ hosting is one less thing to caveat in a tender or an onboarding call — and one less follow-up email to send explaining where the servers actually are.

What still leaves New Zealand — and why

Data doesn’t leave New Zealand as a rule. The exceptions are narrow and opt-in: specific features — address autocomplete, AI note clean-up, Xero invoice sync, payment processing — call an overseas provider because that’s who provides the service, and only when your agency has actually turned that feature on. Nothing leaves as a side effect of ordinary, everyday use of Trackr. If your agency never opts into those features, your data simply stays where it started.