26.08.2026
16:16
We have recently started testing the AI Concierge in WEBCON BPS 2026.2.1.62.
For my first tests, I deliberately chose a very simple and realistic end-user scenario: creating a software bug ticket from a short natural-language description including a screenshot (with application name and error message)
The form contains, among others, the following fields:
Application
Requester
Type (Feature Request, Change Request, Bug Report)
Priority (Low, Medium, High)
Title
Description
I tested mainly with Gemini 2.5 Flash and also with GPT models.
Semantic mapping of form values
One test prompt was equivalent to:
I get an error when saving in the fixed-term deposit process. It is not urgent. Please fill in the form. The requester is John Doe.
The Concierge populated the title, description and requester, but did not populate several values which, in my opinion, should be straightforward for an LLM to infer.
For example:
"error when saving"
→ Bug Report
"not urgent"
→ Low
"fixed-term deposit process"
→ matching application "Festgeld/BV inst. Kunden"
Interestingly, the Concierge even identified Festgeld/BV inst. Kunden as the likely application, but did not select it because the exact choice value had not been explicitly mentioned by the user.
The same happened with the priority: it explained that not urgent had been provided, but the user had not explicitly specified one of the available values Low, Medium or High.
I then changed the instruction to explicitly tell the Concierge:
Infer appropriate values for choice fields from the content, even if I don't use the exact labels.
With this additional instruction, the result was much better. The Concierge correctly populated:
Application → Festgeld/BV inst. Kunden
Requester → John Doe
Type → Bug Report
Priority → Low
Title and description
So the model is clearly capable of making these semantic mappings.
This raises the question whether the default Concierge instructions are intentionally very conservative regarding Choice/People field values.
From an end-user perspective, I would expect semantic matching to be one of the main benefits of using an AI assistant. A normal user should not have to know that they need to explicitly tell the AI to infer values instead of using the exact labels available in the form.
Current user context
One limitation I find particularly surprising is that the Concierge apparently does not know the identity of the currently logged-in WEBCON user.
For example:
I am the requester.
or even:
Fill the Requester field with my username.
could not reliably be resolved.
In one test, the Concierge explicitly explained that the current/session user was not available in the provided FormContext.
In my opinion, the identity of the user interacting with the Concierge should be fundamental context for an assistant integrated into the WEBCON Portal.
For a ticket form I would actually expect the Concierge to infer the Requester from the current user even without explicitly saying “I am the requester”, unless the process or prompt indicates otherwise.
At the very least, expressions such as “I”, “me” and “my” should be resolvable to the currently authenticated WEBCON user.
This would be useful far beyond this particular example:
Show my open requests.
Assign this task to me.
Use my department.
I am the responsible person.
Without knowing which user it is currently assisting, many very natural Concierge interactions are difficult or impossible.
Attachments
Another limitation is attachment handling.
A screenshot uploaded directly to the Concierge chat can be analyzed by the model. However, the Concierge cannot add this uploaded file as an attachment to the current workflow instance.
For a very typical scenario such as:
Here is a screenshot of my error. Please fill in the bug report and attach the screenshot.
the user therefore still has to upload the same file manually to the workflow.
The Concierge does have access to existing workflow attachments, provided that the user explicitly selects them as context. However, this is not very transparent for a typical user: they have to click the small and rather unobtrusive attachment indicator (e.g. 1/1) and then explicitly select an existing workflow attachment via a checkbox.
In my test, after selecting an existing PDF this way, the Concierge was able to analyze and summarize its contents correctly.
However, when I explicitly asked it to “analyze the workflow attachment and write a summary into the Completion Information field”, it returned the summary in the chat instead of writing it into the existing and editable form field.
Consistency
I also noticed significant differences when repeating the same prompt with the same screenshot using Gemini 2.5 Flash.
Across several runs, different subsets of the available information were used:
one run mainly populated the description,
another additionally classified the ticket as Bug Report,
another generated a title,
another correctly recognized and selected the application from the screenshot,
in another run the phrase “I am the requester” was effectively treated as if I were a value to search for in the Users & Groups data source.
The individual capabilities are obviously available, but they were not used consistently in a single run.
Performance
The response time also seems quite high for interactive form assistance.
With Gemini 2.5 Flash, many of these relatively simple requests took approximately 15–30 seconds.
This is noticeable when the expected result is only the population of a few form fields.
Overall impression
The Concierge is technically interesting, and these tests show that the underlying models are capable of much more than the initial results sometimes suggest.
However, this was intentionally a very simple use case:
A user describes an application error in normal language and expects the Concierge to fill in a bug-report form.
For such a scenario I would expect the assistant to:
understand the description,
semantically map it to the available form values,
know who the currently logged-in user is,
populate all values that can reasonably be inferred,
ask only about information that genuinely cannot be determined,
and ideally handle the supplied screenshot as a workflow attachment.
At the moment, too much knowledge about how to prompt the Concierge seems to be required from the end user to achieve this reliably.
I would therefore be interested in WEBCON's view on a few points:
Is the conservative semantic mapping of Choice fields intentional?
Are there plans to provide the Concierge with the current authenticated user as part of its context?
Are workflow attachments / transferring chat uploads to workflow attachments planned for the Concierge?
Are improvements regarding consistency and response time planned?
Is there currently any way for application designers to provide additional general instructions to the Concierge, e.g. that semantic mapping of Choice values is desired?
I would also be interested in experiences from other users who have already tested the Concierge with real-world forms.
EDIT:
I opened AI Concierge on the portal page. Pasted a screenshot of an error message into the chat:
1. screenshot cannot be sent without a prompt...
2. I prompted to find the corresponding ticket app, start a new instance and fill the form
=> Result: I got 4 Links "Start WF" "Start AB" etc. without context (no information which app, which process/workflow)
I clicked on one of the 4 suggestions (which opened a complete wrong app) and tried to go back => context lost no app links available anymore.
To be honest: The idea is nice, but AI Concierge is not usable in production (at least for us)
