Clear answers without the help-center sprawl.

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

Many are delivered quickly. Rare account, payment, or delivery issues may take up to 24 hours to resolve.

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 Starter when you are applying in one lane and want a focused reset.

Premium: $10.00, up to 3 targets, use Premium when you are comparing a few related roles and want the recommended package.

Executive: $20.00, up to 5 targets, use Executive when the search needs senior positioning, a pivot story, or a broader strategy package.

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.

A direct paid request can enter the refund path when an eligible system failure prevents delivery or when the enforced quality guarantee applies.

If a grounded, usable package remains below Blacklight's internal quality standard after the bounded automated refinement sequence, the files remain available and the full payment is refunded. If final integrity checks still find a blocker, no files are released and the full payment is refunded.

Partner-funded requests do not create a refund for the participant. A covered request instead does not count against the organization's plan or event billing.

The quality guarantee covers Blacklight's internal service standard and final integrity checks. It does not guarantee interviews, job offers, compensation, or another employment outcome.

It also is not a customer-requested rewriting service after delivery. Use support for a missing or corrupted file, incorrect contact information, a factual processing error, or another delivery problem. Style preferences, a new target role, or later career changes require a new request.

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.

Special events use the partner request path, but they stay manual by design.

Choose Special event / sponsored program for a job fair, sponsored resume day, workshop, campus event, workforce program, or another time-bound activation. Expected resume usage establishes the planning capacity. The accepted quote then chooses either a prepaid fixed block or flexible capacity with a reservation fee, minimum commitment, delivered-usage reconciliation, approved reserve, and spending ceiling. Blacklight also confirms the access window, participant-data mode, reporting needs, invoice contact, and written acceptance evidence before hosted access, billing approval, or an event workspace is activated.

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. For recurring usage, an organization administrator can stop requests at included capacity, approve a specific additional quantity for the current month, or set a standing monthly overage ceiling. The billing page shows the maximum quantity and estimated maximum bill before the change is confirmed. Special-event capacity is quoted and reconciled separately.

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.

Visibility depends on the person’s assigned partner role, location scope, and event access mode. Organization administrators, location managers, and participant-support staff may receive scoped request details when they are responsible for participant operations. Reporting-only users receive aggregate program reporting instead of participant records.

Special events default to aggregate-only organizer reporting. Sponsors do not receive attendee names, contact information, resumes, request logs, portal access, or recruiting rights merely because they funded the event. The portal also does not expose full generated resume text simply because a request exists.

Partner portal access starts with an approved work email.

Staff use the partner sign-in flow, confirm the email code or sign-in link, and complete verification with a compatible authenticator app before the workspace opens. If someone is not on the allowlist yet, they can submit an access request for admin review; that request does not bypass approval.

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.

Monthly history exports summarize request counts, delivery counts, people helped, delivery-open rate, turnaround, and support-ticket volume for the current partner or location scope. Admin-only cost, internal intervention, cross-partner, and raw diagnostic telemetry stay out of the partner workspace, and reporting does not expose applicant names, resume artifacts, or free-text target details.

Organization administrators manage the full account, including billing and teammate access. Location managers administer assigned locations. Participant-support staff work with participant requests and support inside their scope. Reporting-only users receive aggregate reporting without participant names, contact information, request logs, or support records.

Sponsors do not receive a portal role merely because they funded an event.

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 formal trust follow-up. 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.