For user facilities

Soon you have to open the doors to people you have never met.

A research center reports on itself. A user facility has to find outside researchers, work out whether it can do what they are asking, review them, train them, schedule them, and then account for every hour it gave away.

That is a different job from the one most center software was built for, and it is the one we are building for now.

Help us build it See the whole product

The distinction

Your user program was built for people who already know you.

Most facility intake was designed around collaborators. They knew which instrument they wanted, they knew someone on staff, and they could write a proposal in your program’s own idiom because they had read a dozen of them.

The people you are now asked to reach cannot do any of that. They are at a two-year college, a primarily undergraduate institution, or a small company. They have a question, not a protocol. They do not know your instrument names, and a request form that opens with a three-page project description and biosketches is where they stop.

They cannot find you: Your capabilities live in a proposal table and a page of prose. Someone searching for the measurement they need has no way to land on the instrument that does it, and no way to tell whether it applies to their material.
The first conversation does not scale: Every serious enquiry becomes an email thread with a staff scientist, answering the same twenty questions about sample form, quantity and what the tool can actually resolve. It is the best part of your service and the least repeatable.
Then you have to prove it: Hours by user category, institutions reached, training delivered, publications that acknowledge the award. All of it reconstructed at the end of the year from calendars and memory, for a report that has to be accepted before the next increment arrives.

What we are building

A front door, and everything behind it.

Not a booking system. You almost certainly have one, and it works. This is the part before the booking and the part after it, which is where the work actually piles up.

A capability people can search

Every instrument as a real record: technique, materials it suits, sample form and quantity, what it can resolve, how much time is available, and how long the queue is. The table you already had to write for your proposal, turned into something a stranger can find and a machine can read.

The first conversation, held for you

A researcher describes what they are trying to find out, in their own words. They get a grounded answer about whether you can do it, which instruments apply, and the questions your staff scientist would have asked them anyway. A clear no when the answer is no. And a structured request drafted from what they said, rather than a blank form.

It answers from your capabilities only. It never guesses about your instruments.

Review and allocation you can defend

Requests arrive complete, screened for duplicates and flagged where they need a second look. Your reviewers decide. Every request carries what kind of user it came from, so the balance you promised across first-time users, industry and your own people is a query rather than an argument.

Declines are kept, with reasons. They are the clearest signal you have about what to build next.

Onboarding that finishes

Agreements, training, safety clearance, export control, samples in transit. Each with an owner and a date, chased without anyone remembering to chase. Run a cohort through it after a recruitment workshop rather than one person at a time.

The numbers, as a byproduct

Hours by instrument and by user category, institutions reached and what kind they were, users trained, publications that acknowledge the award, satisfaction and what you did about it. Recorded as the year happens, because every step above already produces it.

Your facility decides its own process. Review steps, who approves, how many user categories you balance across, what onboarding requires. Those are yours to compose and change, not ours to fix in advance, because no two facilities run this the same way and the ones standing up now have not decided yet.

Who it is for

Facility and node directors: You committed to a share of instrument time and a user base you have not met yet. See where both actually stand, early enough to do something about it.
User program coordinators: You are the advocate every applicant is told to contact before they submit. That is the most valuable thing you do and the first thing that breaks when the volume arrives.
The researcher outside: Ask a question in plain language, find out in minutes whether this facility is the right one, and get help writing the request instead of a blank template and a page limit.

Who builds it

We already run the sites these programs share.

SimplyScholar is built by KZN Consulting. We have run National Science Foundation (NSF) program and center websites for over a decade, including the program’s own site one level above any single center. For Materials Innovation Platforms (MIPs) that means we have seen what every platform in the program has to show, and what it gets asked for again the following year.

We have also done the collection itself for individual centers: the roster, the publications, the outreach numbers, kept current between reports rather than assembled at the end. That is where the rest of this comes from.

We would rather build this with you than sell it to you.

The facility side of this is being designed now, and we are looking for a small number of facilities standing up their user programs to shape it. That means telling us how your intake actually works, what you dread about the reporting, and where the current process loses people.

No pitch deck, and nothing to buy today. Design partners get the thing they helped specify, first.

Start the conversation