Frequently asked questions

Yes — the interface is a client of the same API, so there is no capability reachable through the screen that is unreachable through the wire. That is the structural version of the promise, rather than a policy that could quietly lapse.

Today we issue them — tell us what you are building and we will set up a client and a sandbox. Self-serve registration from a developer dashboard is being built and is not shipped yet.

Yes — a pass is a balance held against a person, sold through the normal invoicing, and drawn down by checking them in. Every movement is recorded, so the totals reconcile without anybody keeping a separate tally.

Yes. Check-in is its own permission, so somebody on the door gets the check-in screen and nothing beyond it.

Scans queue on the device and replay when the connection returns, each with an idempotency key so a replayed scan cannot draw a balance down twice. While offline the screen says the balance is unknown rather than guessing, and the person on the door uses their judgement — which is the honest behaviour for a venue with bad signal.

Yes — a pass is a balance held against a member, sold through normal invoicing and drawn down at check-in. Every use is recorded, so the totals reconcile without anybody keeping a separate list.

Yes. Check-in is its own permission, so somebody on the door sees the check-in screen and nothing else.

Yes, but it is not only a CRM — the contacts live in the same database as scheduling, work, invoicing and messaging, so a deal becomes a job becomes an invoice without an integration in between. A standalone CRM holds the contact and hands everything downstream to another tool, which is where most of the re-typing in a small business comes from.

Yes, over the API, in bulk. Talk to us about the shape of what you have and we will tell you honestly whether it is an afternoon or a week before you commit to anything.

Yes. Organizations are isolated from each other by default, and what is shared between them is shared as an explicit fact rather than by giving one access to the other’s records.

Yes — that is the most common use. Courses and completions attach to the same people records as everything else, so training status is a property of a person rather than a separate spreadsheet.

Yes, in full, over the API, without asking us. Every record the interface can show you is readable programmatically, which means an export is something you can run yourself on any schedule rather than a request you file with support.

You take it with you, and the ability to do so is treated as a feature we maintain. We would rather a customer stay because the platform is worth paying for than because extraction is painful.

It is a replacement for the part of your group chat that should have been kept — decisions, answers and agreed process. Chat is good at conversation and bad at memory; this is the other way round.

Yes — attendees are contact records in your own system, not a list a ticketing platform lends you. That is the difference that matters after the event, when following up is the whole point.

Yes — the event, registration and entry surfaces are all available over the API, so you can design the public experience yourself and use the platform as the engine behind it. utahsevents.com is a site doing exactly that.

Yes — locations, spaces and things live in one registry, because they are the same question at different scales. A venue contains rooms, a room contains equipment, and each can independently be bookable, rentable or counted.

Yes. Marking an item rentable and giving it a rate card makes it quotable and invoiceable through the same money surface as everything else, so a rental is not a separate business system.

Against the record they belong to, with the record’s permissions, in the platform’s own storage. They are reachable over the API like anything else, so they are included in an export rather than stranded in a drive.

No — that is the point of it. A form on the site you already own can post straight into the platform, so you can keep your existing site, your existing designer and your existing host.

Intake is rate-limited and carries abuse detection, and a submission is a reviewable record rather than something that fires straight into your workflow. You can require acknowledgement before anything automated acts on it.

Yes. Permissions are granular and scoped, so a resident sees their own household’s account and the shared information the committee publishes, and nothing about their neighbours.

Yes — the hall, pool or guest parking are items in the registry with booking switched on, so availability is real and double-booking is not possible.

Household mode hides the commercial half of the platform — no pipeline, no invoicing surface, no reporting suite — and leaves people, calendar, jobs, files, questions and automations. It is meant for households that are genuinely complicated: shared care, an estate, a house with several adults, a family managing an elderly relative’s affairs.

Yes. The mode is a setting on the organization, not a different product, and changing it changes which menu you see. Nothing is migrated and nothing is lost.

From yours. The sending address is a domain you control so that SPF, DKIM and DMARC align — a message sent as your brand from somebody else’s domain is the most reliable way to land in spam.

Yes, per message type. Automation can generate into a review queue rather than send, which is how you turn it on gradually instead of trusting it all at once.

Yes — a member can post a need and whoever handles that kind of request picks it up, with the whole exchange kept against the record. It works the same way for a business collecting quotes from suppliers.

Yes. Course completions are recorded against a person, so "is everyone on Saturday trained" has an answer, and a rule can restrict an assignment to people who hold the completion.

Down to the individual action on the individual module — reading invoices is a different permission from creating them, which is different again from voiding one. Roles are assembled from those, so you can describe a real job rather than approximate it.

Yes, with different permissions in each, under one identity. That is the normal case for an agency or a bookkeeper, so it is a first-class arrangement rather than a workaround.

Task apps handle one-off lists well and recurring, templated work badly — and they do not know about the people, money or documents around the work. Here a project sits in the same database as the contacts, the schedule and the invoicing, so finishing a task can release an invoice or trigger a message.

A PTA needs four things in one place: a member list, roles with different levels of access, volunteer sign-ups tied to real dates, and money it can account for. EveryonePlans covers those together, which matters more than any single feature — the usual PTA failure is that the member list, the sign-up sheet and the accounts live in three tools owned by three people who rotate off the committee.

Yes, and this is the thing most tools get wrong for volunteer organizations. Roles are built from individual permissions, so the treasurer can see the accounts without seeing everything, and a class rep can run a sign-up without touching money.

Access is a role you reassign, not an account somebody keeps. The records belong to the organization, so a handover is a permissions change rather than a box of paperwork and a shared password.

Yes — an invoice can be part-paid, and deposits are credited against the balance automatically with both movements posted to the ledger. Nothing has to be tracked alongside in a spreadsheet.

There is a real double-entry ledger underneath. That matters because it makes the books balance by construction — a list of invoices can disagree with a bank account and never tell you.

It replaces the spreadsheet between your operations and your accountant, not necessarily your accountant’s software. Everything is readable over the API, so whoever does your books can pull exactly what they need on whatever schedule suits them.

Yes — introductions are attributed at the point they happen and rewards are granted by rule, with a review step before anything is issued. That review gate is what makes an automated scheme safe to leave running.

Yes — everything is readable over the API, in full, without asking us. If you would rather report in a spreadsheet or a BI tool, the platform is a source rather than a destination.

Yes — a bookable resource can publish a page that shows genuine availability and takes bookings without a login. It reflects real commitments rather than a calendar kept in parallel, which is why the slots on it can be trusted.

It is for finding a time across a group of people whose calendars you cannot see — a committee, a volunteer crew, a family. Each person marks what works and the overlap is shown, which is the part a shared calendar cannot do.

Yes. The booking surface is available over the API, so you can either link out to the hosted page or build the whole flow into a site you own.

No. A form on the site you already own can post straight into the platform, and everything the interface does is available over the API — so you can keep your site, your designer and your host.

Yes — availability polling asks a group for the times that work and shows you the overlap. It exists precisely for the case where the people involved do not share a calendar you can see.

Yes, as a first-class thing rather than as a copied checklist — recurring work regenerates on its own schedule and stays attached to the customer and the calendar. That is the case most task tools handle worst, so it is worth checking against whatever you use now.

Yes. Project templates hold the sequence once; every instance gets the current version, so improving the process improves every future job rather than only the next one somebody remembers to update.

Yes — a payment can be held against a specific commitment and released only with a recorded reason, with a dispute process for when the two sides disagree. It is intended for arrangements between parties who do not yet have a track record with each other.

A PTA needs four things in one place: a member list, roles with different levels of access, volunteer sign-ups tied to real dates, and money it can account for. EveryonePlans covers those together, which matters more than any single feature — the usual failure is that the member list, the sign-up sheet and the accounts live in three tools owned by three people who rotate off the committee each year.

Make the sign-up a real list of slots attached to the event, so people claim a place themselves and everyone can see what is still open. In EveryonePlans the slots carry a capacity, the reminders go out on their own before the day, and afterwards the event keeps its own record of who actually turned up — so next year starts from evidence instead of somebody’s memory.

Record the money against the person who paid and the thing they paid for, so "who still owes?" is a list you open rather than a spreadsheet you rebuild. EveryonePlans keeps dues, subs, match fees, tickets, class passes and donations on the same member record, and the treasurer can be given the accounts without being given access to everything else.

Keep the records owned by the organization rather than by the person who set them up, and make access a role you reassign rather than a password you pass on. That is how EveryonePlans works: the outgoing treasurer’s role goes to the incoming one, the member list, accounts, files and notes stay exactly where they are, and the handover takes minutes instead of a box of paperwork.

Usually yes — the tools that most often collapse into EveryonePlans are a CRM, a scheduler, an invoicing tool, a forms tool, a mailing tool and a file drive. The saving people notice is not the bill; it is that an enquiry becomes a job becomes an invoice without anybody typing it three times, because most small-operation admin is reconciling tools that were never introduced to each other.

Yes — EveryonePlans has a Household mode that shows a menu built for a home instead of an office: one calendar everybody can see, recurring jobs that come back on their own, and documents kept with the thing they belong to. It is the same system a club or a company uses, so if the way you use it changes later, nothing has to be moved.

Yes — that is the intended setup, not a workaround. Keep the site you have and connect it to EveryonePlans over the API: public forms post straight in as structured records, and webhooks push changes back out. If you would rather not run a front end at all, you can use ours until you want your own.

Yes. It is a versioned REST API covering the whole system, with a consistent response envelope, a closed set of error codes, cursor pagination, idempotency keys on writes, signed webhooks with delivery retries, and a sandbox mode for testing. It keeps growing, additively — new capabilities and fields appear, existing ones do not change meaning or vanish — and anything that genuinely has to break ships as a new dated version while the one you built against goes on working.

Today, credentials are issued by us — tell us what you are building and we will set up a client and a sandbox for you. Self-serve registration from a developer dashboard is in progress and not shipped yet; we would rather say that plainly than have you discover it after signing up.

Yes. The platform is multi-tenant at its foundation rather than by configuration, so an agency or consultancy can run many client organizations side by side, each isolated, each with its own users, branding and domain. Permissions are scoped per organization, so somebody who works across two clients sees exactly what they should in each.

EveryonePlans is one place to run a group: the people, the plans, the money and the messages together, instead of spread across a chat, a spreadsheet and somebody’s inbox. PTAs, clubs, sports teams, HOAs, households, nonprofits, event organizers and service businesses all run on it, and a versioned API sits over the whole thing for anyone who wants to build their own front end on top.

It is for any group that has to organize people and keep track of what they are doing — a PTA, a club, a sports team, a homeowners association, a charity, a household, an event committee, or a company with staff and customers. The common thread is not size or industry: it is that the member list, the sign-up sheet, the money and the decisions have ended up in different places owned by different people.

The main difference is that EveryonePlans is designed to be left. Everything the interface does is available over the API, so a customer can put their own front end on top or move their data out in full without asking us — where most platforms in this category are built so that switching is expensive. The second difference is scope: this is not a CRM with add-ons bolted around it, it is one database covering contacts, work, scheduling, money and messaging under a single permission model.

Anything the system records as an event — a lead arriving, a stage changing, a job completing, an invoice ageing, a form being submitted, a scheduled date passing. Rules react to what happened rather than checking on a timer.

Yes. A human approval step pauses the workflow, assigns a task, and resumes with the answer — so automation covers the routine parts without making decisions that need judgement.

Pricing depends on how much of the platform you use and how much setup work is involved, so we quote it after a working session rather than publishing a tier table that would be wrong for most people. That first conversation costs nothing, and it ends with a number.

A straightforward operation is usually running within a couple of weeks; a business with unusual structure takes longer, because we model it properly rather than force it into a default shape. Most of that time is configuration and data, not software — which is why setup is done with you rather than handed to you as a wizard.

Yes. EveryonePlans is a consultancy first, so bespoke work on top of the platform — a custom front end, an integration with something you already run, a workflow specific to your industry — is normal rather than an exception. Where a piece of that work is generally useful, it usually ends up in the platform for everyone.

No. What is public is a property of the records you already keep, so the public view updates when the record does. If you would rather run your own website, the same data is available over the API so it shows the same truth without a sync step.