Build fictional HVAC customer records for an AI office pilot

Keep the workflow structure and remove live identities

Choose a task you want to test, such as an account summary or a quote question queue. List the fields it uses, then write wholly fictional records with those fields. Invent the company, contact, location labels, asset identifiers and message text. Do not begin by copying a real customer record and changing only the name.

A useful scenario keeps realistic relationships: one parent account, two fictional properties, different contact roles and one unresolved question. Label the entire packet fictional and use reserved example domains for any email-shaped fields. Do not include working phone numbers, building access details, actual supplier account references or realistic credentials just to make the demonstration look complete.

Design records that reveal mistakes

Include a clear case, an incomplete case and a contradiction. For a fictional maintenance account, one note can identify Site A while a later message uses an ambiguous nickname. Define the expected behavior as asking which site is meant. The assistant should not silently merge locations or assign authority to a contact because their title sounds senior.

Write an answer key before running the prompt: facts it may repeat, unknowns it must retain, actions it must not take and the human question it should raise. Keep expected answers separate from the input so the tool cannot merely echo them. You are testing an office decision, not creating synthetic evidence for a customer case study or a claim of product accuracy.

Keep test records out of production

Use a separate local packet or an authorized sandbox. Prefix names and filenames with TEST and keep them out of live customer search, scheduling, invoices and mailing lists. Do not create real CRM contacts or send trial messages unless that distinct action is explicitly authorized. A realistic-looking test address can still become an unwanted email recipient.

Review the generated results with the person who owns the workflow. Record observed errors and modify the prompt or input structure, preserving the original test case. When the pilot eventually needs live information, make a separate decision about approved tools, permissions and data minimization. Fictional records can reveal reasoning problems, but they do not prove that a real integration will match production records correctly.

Before you use the result

• Invent records from the field structure instead of lightly masking an export.
• Label the packet and output TEST / FICTIONAL.
• Use non-working example contact details and no access credentials.
• Write expected facts, unknowns and prohibited actions before the run.
• Keep test records and results out of customer communication and production systems.

What the sources support

NIST identifies privacy concerns and generated factual errors. These support using bounded trials; the fictional scenarios and separation checks here are our editorial method. Fictional data is not a guarantee of anonymity for a transformed live dataset, nor proof of production performance.