Show the task.
Describe what a person does with the app, what they expect back and what they do next. If it already runs, show the current tool and the part that needs attention. Use made-up examples where a real record would reveal customer or business information.
List the parts you know about.
The developer, hosting provider, model service, database and document sources are useful names to bring. It is fine if you do not have the whole list. We can scope an initial review to find out what is running and who controls it.
Explain who can use what.
Who signs in? Do staff have different roles? Does the app serve one business or several customers? Which information must stay separate? These answers affect how access and retrieval need to work and what the pilot should test.
Describe the workload.
Bring any existing usage or bills and an idea of the number of users and main tasks. We use that to discuss a starting estimate and controls, then test the agreed behaviour. Do not treat an early estimate as an unlimited allowance.
Name the operating needs.
Say when people rely on the tool, what a failure would interrupt and who can help with source information. Recovery needs, support hours and an escalation contact belong in the scope as well as the hosting itself.
Leave sensitive access for the agreed route.
A description is enough for the first enquiry. Do not send passwords, API keys, private customer records or a whole document library through the contact form. We agree access and information handling before taking those steps.
What to bring to an AI hosting conversation.
You do not need a technical specification. A clear description of the work and the information involved is a useful start.
Let’s look at
your setup.
Tell me what you want the app to do, or what needs attention. We can work out the next step together.
Book a short callOr send me the outline