Trial environments for enterprise prospects, kept away from production
The prospect liked the demo and wants a login for its evaluation team. Sales promised access on Monday. By Friday, the sales engineer is deciding which shared demo stack can stay untouched for two weeks while the next round of sales calls carries on. A prospect trial needs a place on the delivery calendar, with someone responsible for the environment and someone on the buyer's side responsible for the decision. Giving it a separate stack protects the work already in progress. A useful evaluation also needs a clear account of what the prospect will prove there. This guide describes an evaluation of your software by a prospective customer. It uses invented data as the starting point. The dates, limits and workflows below are examples for a team to agree with its buyer.
Agree on the decision the evaluation will support
Start with the work the buyer needs to complete before approving a purchase. A request to let six people explore the product leaves you guessing whether the evaluation succeeded. Ask the buyer to identify a workflow, the person who will run it, and the evidence that person needs to keep.
For an inventory product, that could mean importing an invented order file, assigning the order to a warehouse, and exporting the resulting stock report. The buyer's operations lead should agree what a successful report contains. Record a second case for a rejected file if handling bad imports is part of the purchase decision.
The evaluation record should distinguish a product feature from an integration or an operating requirement. A report generated from invented orders can demonstrate the report workflow. Connecting to the buyer's identity provider tests a different dependency and needs its own owner and access arrangements.
Set the review meeting before opening access. Give the evaluation a start date, an end date and a named buyer who can approve the outcome. Agree who handles questions during the window, including the hours when that person is available. An extension should carry a new end date and a reason connected to an unfinished decision.
Define the boundary around production
Draw the trial's connections before building it. Include its database and file storage, then trace the destinations used by background workers, outbound messages and integrations. Review the configuration with the engineer who runs production so each destination has an agreed trial equivalent.
A separate web address gives people a useful label. The engineering boundary comes from the resources, permissions and network rules behind it. On AWS, the Well Architected guidance recommends account separation between environments. Other infrastructure needs its own documented controls. Record the boundary your team actually configures and checks.
Issue credentials for the trial's resources. Keep their permissions limited to the evaluation, and check the application's effective configuration before inviting the prospect. A deployment file can name a test database while a worker still reads an older connection string from another location.
Rehearse the outbound actions in the agreed workflows. Capture mail in an approved test destination and route external calls to a test endpoint or a controlled substitute. Record which behavior is simulated. A report about an integration should say whether the real service participated, because an approved substitute proves only the path exercised through that substitute.
Start with invented records and record any exception
Use a prepared dataset that supports the agreed workflows, with enough history to make the screens useful. Dates should cover the period the buyer will evaluate. A report for this month needs records in this month, even when the seed file was written last quarter.
Tell the evaluation team which data it may upload. Put that instruction beside the upload step and in the handoff note, where the person importing a file can find it. Agree a route for questions if the buyer believes its own records are necessary to prove a requirement.
An evaluation that requires real records needs approval for that use before the upload. Have the responsible people agree the permitted fields, access, storage and disposal arrangements. Keep it outside the invented dataset procedure until those decisions are recorded. The environment's existence alone does not settle data handling.
Keep the environment out of the shared demo reset schedule. A prospect may spend an afternoon building a report it needs to present the following morning. Agree a reset with the buyer and save any required evaluation evidence before running it. Record who can request the reset and who performs it.
Rehearse access as each intended user
Prepare a named access list with the buyer. Separate the evaluator who runs the workflow from anyone who needs administrative access to configure it. Use individual accounts so the evaluation record can identify who encountered a problem and which permissions that person had.
Test the roles through the application before handoff. Verify the approved actions, then check that an evaluator cannot open administrative functions or another evaluation's records. OWASP's authorization guidance recommends granting only required permissions and validating authorization on every request. Use the application's existing access tests as part of this rehearsal.
Check the sign in path from the kind of device and network the buyer will use. An engineer signing in from an internal network has exercised different conditions from a prospect opening an invitation from its corporate laptop. Resolve the difference while someone from each team is available.
Send the environment address with the first workflow, the permitted data and the contact for problems. Record the access window in the same note. The buyer should be able to start the evaluation from that handoff without reconstructing the plan from a sales call.
Keep changes visible during the evaluation
Record the application build, configuration and dataset version at handoff. Hold routine demo refreshes away from this stack while the buyer works. If a fix is needed, agree a change window and record which workflow must be repeated afterward.
A useful issue report includes the workflow, the evaluator's role, the time and the observed result. Ask for evidence that the teams are permitted to share. Screenshots and exports belong in the same data handling plan as the records they contain.
Review progress against the acceptance record during the window. A blocked sign in and an unsupported product feature need different followup work. Make that distinction in the record so the buyer's final decision can separate an access problem from the behavior it wanted to evaluate.
Document each limit that affects the conclusion. A trial with a smaller dataset can demonstrate the import workflow while leaving the largest production import untested. Write down the remaining test and its owner before treating that requirement as complete. The same applies to an integration that ran through a substitute.
Close access and keep the decision record
Use the review meeting to record each workflow's result, the evidence the buyer accepted and any remaining question. Keep the build and configuration reference with that record. A later discussion about the evaluation should start from the version the buyer actually used.
Confirm whether the trial will close or continue under a new agreement. If it closes, remove evaluator access and revoke the trial's integration credentials through the systems that issued them. OWASP's secrets lifecycle guidance calls for revocation when a secret is no longer needed and a defined expiry where possible. Verify the result rather than assuming a stopped server has ended every form of access.
Complete the agreed disposal work for the database and uploaded files, including any retained copies covered by the plan. Record what was removed and what remains, with its owner and retention date. Evidence needed for the purchase decision can have a different retention period from the environment, provided that arrangement was agreed.
Petrichor builds demo environments away from production and starts each environment with a written spec covering servers, network, data, access and how long it should live. Bring the buyer's evaluation workflows to a call with a consultant so the trial can be scoped around the decision you need to make.