La triste realidad de los eventos técnicos: el no-show

Desde hace unos años observo una tendencia en los eventos técnicos a los que asisto o los que colaboro a organizar. Esta tendencia es la creciente ausencia no notificada, o el temido no-show.

Se considera no-show cuando una persona registrada para un evento no asiste, sin cancelar su entrada. También es no-show cuando la persona avisa el mismo día o el día anterior, ya que deja muy poco márgen para poder reutilizar la entrada a reajustar la logística.

Un no-show individual no es un problema. Todo el mundo tiene alguna cosa que le surge en el último momento. El problema es cuando el no-show es masivo, como lo que le pasó a Luís Fraile no hace mucho.

Te voy a poner un ejemplo: si esperas 100 personas en un evento, siempre cuentas con un porcentaje de no-show de digamos 20%. Entonces, dejas que se apunten 120 contando que al final irán 100. Compras comida para 100, pides merchanidising para los 100, buscas un sitio para los 100…ya me entiendes. Al final vienen 20. De 120. Te sobran tres cuartos de todo. Los patrocinadores con cara de circunstancias. Y tú, con cara de tonto…

Evidencia empírica (y subjetiva) de los últimos eventos en los que estuve colaborando

  • SharePoint Saturday Barcelona 2017: creo recordar que se apuntaron 180 y vinieron 130. No-show: <30%. No está mal (y toco madera)
  • SharePoint Saturday Madrid 2018: apuntados 300. asistieron 270. No-show de 10%. ¡Para tirar cohetes!
  • Azure Bootcamp 2018 Barcelona: apuntados 150, asistieron 70. No-show de >50%
  • Insider Dev Tour 2018 Barcelona: apuntados 220, asistieron 70. No show de >65%. Suerte que pudimos llevar la comida sobrante a un comedor social.

Salvo los eventos de SharePoint, y creo que es porque la comunidad de SharePoint es especialmente cohesionada, los eventos técnicos acusan una tendencia a la alza de no-shows.

¿Por qué pasa esto? Causas del no-show

¡Ojalá lo supiera! Según he podido hablar con otros compañeros y compañeras en la comunidad, hay varios posibles factores en juego:

  • La fecha o el día de la semana el evento va mal a la gente
    • Pero entonces, ¿por qué se apuntan si les va mal?
  • El formato del evento ya no atrae
    • Hay un debate sobre si los eventos presenciales siguen teniendo validez hoy en día o si se tiene que reinventar el evento en un formato más virtual
    • Pero entoces, ¿por qué se apuntan?
  • La gente no valora lo que es gratis
    • Pero hay eventos gratuitos en los que esto no pasa
  • Cuesta poco apuntarse y no hay consecuencias por no asistir
    • Aquí estoy de acuerdo, pero no sé que proponer como alternativa

¿Se os ocurren más ideas sobre las posibles causas?

¿Qué podemos hacer para prevenir el no-show?

Si lo supiera…montaría una startup vendiendo la solución. De lo que he escuchado en la comunidad, hay dos posibles alternativas:

  • Poner un precio simbólico al evento (tipo 5-10 euros) para que no sea gratis
    • A Microsoft le funcionó bastante bien para la DotNetSpain hace unos años
    • Pero
      • Ya es una barrera para asistir, aunque sea más psicológica que real
      • Hay eventos que por la licencia de marca (como los “____ Saturdays”) que obligan a que el evento sea gratuito
      • Obliga a los organizadores a tener registro fiscal (que es un dolor de cabeza y sumidero de tiempo) y obligaciones con Hacienda
  • Llevar un registro de los no-shows pasados y poner un “baneo” a la persona reincidente
    • No me parece mal y sé que hay grupos de usuarios en Europa y EEUU que lo usan con éxito
    • Pero no sería una solución a corto plazo. Además, con el tema de GDPR esto de guardar los datos de los asistentes pasados es más peliagudo.

Hasta aquí mi granito de arena. Estoy esperando ver el debate sobre estas y otras propuestas.

 

How to Create a Graph Schema Extension using Graph Explorer

I’ve been doing a lot of SPFx, NET Core and Office 365 related development and I have several stories to share.

During the implementation of one of the features in a custom API application, I had to create a schema extension in Microsoft Graph for a Group object, for the purposes of classification. As I stumbled upon a non-intuitive behaviour of the API in Graph Explorer, I hope to save you a couple of hours if you have to do the same.

I went to the extensive Graph documentation to see how to perform such a call to MS Graph. It didn’t seem particularly difficult, just a POST with JSON data on the schemaExtensions endpoint.

In Graph Explorer application that I was using, I kept getting “Request denied due to insufficient permissions”. I double and triple-checked that my Graph Explorer indeed had the needed permissions (Directory.AccessAsUser.All). No matter what I did, I kept getting the same error.

In the end, it seemed to be a limitation on Graph Explorer client. To overcome it, Microsoft added a workaround:

  • Register another Web / API application in Azure Active Directory
  • Add the required permissions to create schema extension to that application
  • In Graph Explorer, prepare a POST request to schemaExtensions endpoint
  • Add “owner” property in the JSON payload, with the value of the authorized application App ID
  • Voilà! The schema extension is created.

My schema creation request JSON payload was like this: