I developed and delivered training for an Airtable CRM I designed, combining in-person instruction with practice in a sandbox. Each participant completed six days of sandbox training and could perform all standard simulation tasks by the end.
The portfolio includes a Google Slides version of the in-person instruction and a smaller browser simulation using fictional records. Organizational details and participant numbers are withheld for confidentiality.
Analysis: defining successful performance
Developing the CRM involved gathering user requirements and designing record relationships to support follow-up between colleagues. For this portfolio, I selected one workflow from the broader training: recording a customer inquiry received through an emailed call message.
Successful performance means the inquiry is recorded accurately and reaches the employee responsible for the account. Those outcomes established the instructional scope and the criteria for reviewing learners’ work.
Design: demonstrate, then practice
The lesson follows a sample request from Alex Chen for a product sample, explaining what employees should verify before saving changes. The practice inquiry uses different information so learners must apply the procedure rather than copy the example.
| Workflow step | Instructional focus |
|---|---|
| Find the company and caller | Compare identifying details before deciding whether a new contact is needed. |
| Record the inquiry | Link the records correctly and include enough information for follow-up. |
| Notify the account owner | Verify the recipient and the link to the saved interaction. |
Sandbox practice allowed employees to work with records without affecting live customer information. The public simulation preserves that approach within a narrower task.
Development: building the portfolio simulation
I supplied Claude with CRM specifications and screenshots to develop the browser simulation. Claude wrote the code, while I tested successive versions and directed revisions when record behavior did not match the workflow.
An early version began inside the CRM, skipping the need to interpret the incoming communication. I added a simulated inbox so learners would have to extract the relevant information before recording it.
The simulation permits mistakes and assesses saved work rather than requiring a fixed sequence of highlighted controls.
- Feedback addresses the result: Checks identify problems with record links and notifications, alongside missing information.
- Learners can make corrections: They can review the feedback, edit their work, and submit again.
I also revised the slides to clarify the distinction between the contact record and the interaction documenting the inquiry.
Implementation and evaluation
I delivered the training to a small workplace group, with each participant completing six days of practice in the broader sandbox.
| Evidence | What it supports |
|---|---|
| All participants completed every standard simulation task by the end of training. | Proficiency on the tasks covered by the sandbox training. |
| The team has reported no serious CRM errors or need for substantial rework or adjustment. | A favorable operational indication, although errors were not formally tracked. |
Evaluation was practical rather than a formal study. There was no baseline error rate or comparison group, so the results do not establish a measured reduction in workplace errors. The public browser simulation is a smaller adaptation of the sandbox used in training; the completion result applies to that broader training environment.
Lessons learned
- System knowledge made AI-assisted development workable. Having designed the CRM, I could specify the required behavior and recognize when generated code misrepresented it.
- Prototype testing improved the task scope. Adding the inbox restored the need to interpret a message before entering information.
- Fidelity depended on the workflow. Preserving the relevant record relationships mattered more than reproducing every software feature.