Clear answers without the help-center sprawl.

Most requests start moving right away after payment or partner approval.

Many are delivered quickly, but if manual review or payment verification is needed, allow up to 24 hours.

You will get a status link so you can see where the request stands, and you will get an email when delivery is ready.

You need an email address, a selected tier, and at least one target role.

A current resume, pasted job description, strong role details, and concrete work examples all help the process.

Yes. You can upload your current resume as .doc or .docx.

Uploading is optional, but it usually helps because it gives the system more real material to work from.

The tiers are built around how wide your search is and how much support you need.

Starter: $5.00, up to 2 targets, use Basic when you are applying in one lane and want a fast reset.

Premium: $10.00, up to 3 targets, use Premium when you are applying across a few related roles.

Executive: $20.00, up to 5 targets, use Executive when you need a broader search package and more follow-through help.

Yes. The resumes stay clean, readable, and ATS-safe.

The system scores and refines each version before delivery, and the higher tiers add more support around the resume instead of turning the resume itself into a cluttered document.

Yes.

Before payment and submission, you can still change your tier, add or remove targets within the tier limit, and review the request before it goes through.

Refunds are tied to failed or terminal requests that were paid but never delivered.

If the system cannot complete the request and the order meets the refund rules, it can trigger the refund path automatically. Admin review can also step in when needed.

Deletion requests are scheduled instead of being erased instantly.

Right now the system gives a roughly 3-day buffer before purge, sends a notice before deletion, removes generated files, scrubs personal data from the request, and keeps only a limited recoverable case file for about 120 days unless a legal hold applies.

Support records and analytics logs are also reduced over time according to retention rules rather than being kept forever.

If you opt in, yes.

The system can send a short follow-up a few days after delivery and another one a few weeks later so you can share whether you used the resume and whether it helped. Those feedback emails include an unsubscribe option.

Your status link is the main control point after submission.

You can check progress there, see the request state, and resend the delivery email if you need it again. If you opted into follow-up, that is also where the later feedback flow connects back to the request.

Your information is used to generate the resume package, deliver it, support the request, and run the status and support workflow.

It is not there to fuel a third-party ad stack. If you opt into product-improvement feedback, anonymized outcome signals can later be used to improve resume quality, but that is separate from the core request itself.

Blacklight records first-party product signals such as page views, selected actions, request status movement, checkout handoff state, delivery events, support routing, and feedback opt-in state.

Those signals help operate the service, diagnose broken flows, understand whether requests are getting delivered, and improve the public experience. They are not a hidden ad profile, and the public site is not built around third-party advertising trackers.

No off-site ad tracker is required for the core experience.

Optional site analytics respect browser signals like Do Not Track and stay inside the app data flow instead of leaning on a pile of third-party marketing scripts.

Blacklight does not keep every piece of personal data forever.

Request data, uploads, generated files, support records, and analytics-related records each have their own retention window. Some records are minimized, redacted, or cleared on schedule as part of normal system cleanup even if no one submits a deletion request.

A deletion request is the faster path for a specific person or request. That process moves the request into the deletion workflow, but it is not the only way personal information ever gets reduced or cleared.

Partners can use a hosted intake page on Blacklight, an embedded intake on their own website, or both.

The intake is tied to the partner setup, the allowed tiers, and the partner billing model so the experience stays simple for the end user.

After approval, the partner gets portal access and a real onboarding path.

That is where the organization can confirm support contacts, launch details, embed setup, and who should have access on their side. The goal is to get the account launch-ready without turning setup into a long email thread.

At minimum, Blacklight needs a real partner owner, a billing contact, and a public support destination if the intake will be public-facing.

Larger organizations may also need branch/location setup, staff access decisions, and a trust or procurement review before they go live.

Partners are expected to handle their own user or program questions.

Blacklight handles platform issues, process failures, output-quality issues, and privacy or trust matters. Partner-owned questions should route to the partner’s support contact instead of turning into a Blacklight support queue by default.

Yes.

A partner should have at least one real internal owner who can handle setup decisions, user-facing questions, and day-to-day coordination. Blacklight is not meant to become the partner’s front-line program manager by default.

Trial setups can leave that blank for a while.

Once a partner is active and using a public intake, they should have a support destination in place so their users are not left guessing where partner-owned questions should go.

Use the hosted page if you want the fastest launch or do not have a website setup that makes embedding easy.

Use the embed if you want the intake to live inside your own site experience. Both paths run through the same partner-bound setup, so the main decision is what fits your organization’s user experience best.

No. Partner intake flows are designed for invoice-backed billing rather than card checkout.

Tier access and partner setup are controlled on the admin side because they are part of the commercial relationship, not a self-serve pricing toggle.

Partner billing runs through the account relationship, not the public checkout flow.

That means invoice contacts, payment terms, PO handling when needed, and billing status are managed at the partner level. The partner portal is where account contacts can see billing standing and invoice history once the account is live.

A partner should name a real billing contact, and larger organizations often also provide a separate admin or procurement contact.

That keeps billing, trust review, and user-support responsibilities from getting mixed together.

The default model is period-end cancellation.

A partner can stop renewal, but the current paid term stays active through its end date. Normal cancellation does not unwind the active billing period or create a partial-term refund by default.

Partner users can see request status, selected roles, timing, and account-level activity that belongs to their partner scope.

They do not get open access to the full generated resume text just because a request exists. The portal is designed for tracking and oversight, not for exposing every artifact by default.

Partner reporting is scoped to the partner account and is designed around operational totals, status movement, delivery volume, support load, launch readiness, and aggregate quality signals.

Founder-only cost, internal intervention, cross-partner, and raw diagnostic telemetry stay out of the partner workspace. Longer historical reporting should use aggregate or anonymized monthly statements rather than extending retention for applicant PII, resumes, generated artifacts, or free-text target details.

Partner admins handle account-level setup and broader oversight.

Members are for operational users who need to work inside the program. Viewers are for people who mainly need visibility without the same level of operational control. The exact scope can be tightened further when branch or location limits are needed.

Yes.

Larger partners can scope some users to specific locations while keeping partner admins partner-wide. That helps prevent one team from being flooded with requests that belong to another branch or office.

That can be handled later if the organization is large enough or needs it.

Blacklight does not need to force SSO on smaller partners just to get started, but the onboarding structure leaves room for it when a larger institution needs tighter identity control.

Hosted links and embed tokens are controlled on the Blacklight side.

They can expire, be limited, or be revoked, and partner-bound links only work for the partner they were issued for. That keeps public intake access easier to manage without opening the door to uncontrolled reuse.

No.

A partner can have a basic tier arrangement without it becoming an unlimited unmanaged queue. Tier access, allowed roles, and overall usage are still part of the partner relationship and can be limited or adjusted based on the agreement.

Start with the trust center and trust packet.

If your institution needs a deeper review, use the trust contact flow. That creates a structured ticket so Blacklight can respond with the right next step instead of guessing what your reviewer needs.

Not blindly.

Trust and procurement requests go into a controlled review workflow first. From there, Blacklight can send the trust packet, request your institution’s standard questionnaire, or continue the review based on what your team actually needs.

It is the setup-health checkpoint for the partner account.

Before launch, it helps confirm support destinations, access setup, and hosted/embed readiness. After launch, it stays useful as an account-status view so setup gaps and operational issues are still visible instead of getting lost.