What we collect, and what we do with it.

We collect information at three points, and nothing outside them.

When you book a call. The form asks for your student’s year, your email address and a phone number. If you fill in the optional questions afterwards, we also store what you wrote about schools under consideration, test scores, your student’s strengths and what you are worried about. We record your student’s first name and grade if you give them, any message you write us, which counselor’s page you arrived from, which time slot you picked, and the campaign parameters that were in the URL when you landed, including a Facebook click identifier if Facebook put one there.

That last item is worth being precise about. We store the click identifier in a column and nothing in our software reads it back out or sends it anywhere. There is no Facebook pixel on this site, no Google tag, and no analytics product of any kind. Not configured off, not present. The same is true of your email address and phone number, for the reason in the next section.

When you enroll. Your student’s first and last name, graduation year, and an email address if they have one. The package you bought, the price you were quoted, the dates, what you have paid and what is outstanding.

While the engagement runs. What your counselor writes down after each session, the tasks your student owes, documents your student or counselor uploads, and the messages in your family’s threads, including every message our AI agent writes, which is permanently marked as written by an AI and cannot be unmarked.

We do not sell or share your family’s information, and the reason is not a policy we are choosing to follow. It is that there is nothing in this software that could do it. There is no advertising integration, no data broker connection, no analytics vendor, no customer-data platform, and no email or SMS provider. A promise kept this way is stronger than a promise kept by policy, because breaking it would take a code change rather than a decision.

It is also more fragile than it sounds, and you should know which kind of promise you are getting. The day somebody adds an analytics script to this site, this paragraph becomes false without anybody editing this page. We have not added one, and this is the page that would have to change first if we did.

No email has ever been sent by this software. There is no mail provider configured and no code that sends mail. If you hear from The Scholar’s Bureau, a person typed it. We say this here because “we will email you” appears in a few places in the product and is, today, a description of a human being rather than of a system.

Permissions are enforced by row-level security in Postgres, which means they apply to every query regardless of which page or which developer wrote it. The rules that matter to you:

A booking is write-only from the public site. The logged-out website can create a lead and has no privilege to read one back. There is no query a visitor can construct that returns somebody else’s enquiry.

Your counselor cannot see our sales pipeline, and The Scholar’s Bureau staff who are not administrators cannot either. Your counselor sees the students assigned to them and gets a 404, not a “permission denied”, for anybody else, so they cannot even learn that another family exists.

A counselor’s pay rate is absent from anything you are served, as is their internal pay band. Not blanked out: the field is not in the response at all, and there are tests that fail if it appears.

Your student’s records are separated from other families’ at the database level, including in the AI agent’s search, which filters by family before it searches rather than after.

A student cannot get a login at The Scholar’s Bureau unless their date of birth puts them at 13 or over. The check is a database function, it refuses when the date of birth is missing, and it refuses an implausible date rather than letting it through. A student with no recorded date of birth gets no account.

Three limits on that:

It is enforced when a student login is created, not at enrollment. A family can buy a package for a student of any age, and the counselor can work with them. The student simply has no account of their own, and everything runs through the parent. That is a real distinction and we would rather you understand it than be reassured by it.

The date of birth is what you or your student tells us. Nothing verifies it. We record it as attested, which is what it is.

There is no public sign-up. Accounts are created by The Scholar’s Bureau, which is why there is no place a child could arrive and register unsupervised.

The product tells you that document contents are deleted 90 days after an engagement ends, and within 30 days of you removing something. The rule is written, the database can produce the exact list of documents that are due, and the code that deletes them exists.

Nothing runs it on a timer. There is no cron job, no scheduler and no background trigger anywhere in this software. Deleting the documents that are due is a person opening a terminal and running the retention job. So the honest statement of our retention practice is: we have a retention schedule, and it is performed when somebody performs it. Until a run happens, files past the dates above are still stored.

As of 30 July 2026, no run has ever deleted a document. That is a statement about what has happened, not a promise about what will, and it is the sentence to ask us to update. If you want to know whether a run has happened since, ask. Every attempt, including the ones that deleted nothing, is recorded with a timestamp.

Three things are true whether or not a run has happened. When a document is deleted, we keep only a line recording that it existed and was deleted, not its contents. A document belonging to a family whose engagement is still live is excluded from the list, and an engagement with no stated end date counts as live, so a run cannot reach into a family who is still working with us. And a file is only marked deleted after the store has actually been asked to remove it, so a record saying your child’s transcript is gone is never written ahead of the deletion.

You can ask us what we hold about your family, ask us to correct it, and ask us to delete it. Today every one of those is a person reading your message and running a database query. There is no self-service export and no automated deletion, and we are not going to describe one.

One thing you cannot get back by asking: messages in a thread are immutable by design, so that nobody, including us, can quietly edit what was said to your student or by them. If you want a message removed, the honest answer is that we would be deleting a record whose whole purpose is that it cannot be altered, and we would talk to you about it rather than silently do it.

Ask us anything on this page. A person will answer, and if the answer is “we have not built that yet” you will get that instead of a paragraph. Our terms of service is written the same way, and what we don’t do lists the product’s limits.