Your First Customer Pilot: An Access Checklist
Prepare a Rajasthan startup pilot with clear customer roles, test data, account support, access removal, and a written pilot exit process.
Retrospective series date: 2026-09-28. This label describes the series order, not a historical publication.
A customer pilot needs an end date and an access-removal plan. Without them, temporary accounts can become permanent paths into your product.
Use this worksheet before a Rajasthan startup invites its first external users. It also applies to pilots elsewhere in India.
Name the pilot boundary
Write down the customer organization, approved users, data types, intended tasks, and pilot end date.
Agree on one customer contact and one internal owner. Record who can approve new users or changes to access.
An incubator introduction can help you find a pilot. It does not define the customer's access rights or data responsibilities.
Use this pilot worksheet
Download the blank pilot worksheet. Fill in owners and evidence before inviting customers.
| Item | Decision to record | Evidence |
|---|---|---|
| Users | Named participants and invitation method | Approved list |
| Roles | Tasks each role may perform | Access table |
| Data | Minimum fields for the pilot | Data inventory |
| Support | Authorized contact and escalation route | Support instructions |
| Access changes | Person who approves them | Change record |
| End date | Review and removal date | Written pilot scope |
| Exit | Delete, return, or retain each data class | Agreed exit process |
Keep the worksheet in the project record. Do not put credentials or full customer records into it.
Create restricted pilot roles
Start with the smallest access needed for the agreed task. Give each participant an individual account.
A customer observer may need read access. A pilot operator may need to create records. Neither automatically needs administrative control.
Test restrictions on the server. Change identifiers in a request to confirm that another customer's records stay protected.
Prepare a useful demonstration
Use synthetic records for demonstrations outside the approved pilot. Keep demo users separate from customer users.
Make the demonstration repeatable. Record how to reset the data and who may run the reset.
If the product uses an external identity provider, verify callback URLs for the pilot environment. Do not reuse test secrets in production.
Control invitations and departures
Set an invitation expiry. Confirm that only an authorized person can invite a pilot participant.
Test an expired invitation, a reused invitation, and an invitation for the wrong organization. Check that each fails safely.
When a person leaves the pilot, remove membership and revoke the intended sessions. Hiding the organization in the user interface is insufficient.
Plan support before the first failure
Tell users how to report a login problem. Ask them for the time, visible error, and a safe request identifier.
Do not ask them to send a password, bearer token, or identity document through chat.
Use the recovery guide to define evidence for account recovery. A customer contact should not bypass that procedure.
End the pilot deliberately
At the end date, decide whether to extend, convert, or close the pilot. Get approval for the next state.
Revoke temporary credentials. Remove expired memberships. Apply the agreed data treatment. Check integrations and scheduled jobs as well as interactive sessions.
Record the outcome and remaining obligations. Keep only the evidence needed for the agreed purpose.
Contact the NamoID team
NamoID can help review your pilot's login, organization boundaries, and session-removal flow.
Message our team in Slack with your stack, pilot size, and launch stage. We can help you turn this worksheet into implementation tasks.
For local ecosystem routes, use the Rajasthan resource map.